scw%ucla-locus@cepu.UUCP (06/13/83)
From: Steve Woods <cepu!scw@ucla-locus> There is something that I've always wondered about on . . . gets too big for -n. I don't understand how or why tho. Understanding how this works sort of depends on understanding how the PDP-11 addressing hardware works. The problem is that -n DOES NOT make your program separate I/D. What it does (or is supposed to) do is make the text (executable) part of your program pure (read-only) and shareable by other users (so there need only be 1 copy of it in memory at any time). Note that this also saves space in /dev/swap as the text of the program is NOT placed there but rather left in the file from which it is loaded and reloaded from there if necessary (this is one of the reasons that unlink(2) can fail to unlink a file). Due to the way that the PDP-11 addressing hardware works specifing -n can cost you up to 8k(-2) bytes of addressing space (the data space is allocated beginning at the next 8k boundry). The -i option forces separate I/D space (the text portion is pure also) the I space starts at 0 (the stack uses up 8k bytes starting down from 0177776). Giving you 32 Kw of data space ,28 Kw of data space and 8Kw of stack space (Note that the stack can grow (down) at the expense of unallocated data space). <scw> cepu!scw@ucla-locus
ron%brl-bmd@sri-unix.UUCP (06/13/83)
From: Ron Natalie <ron@brl-bmd> Now wait a minute. Steve's letter states the with the -n option the text part of the program is not put into /dev/swap but loaded out of the disk each time and that's why you can't unlink these files...WRONG. When you load a 410 type (one loaded with the -n) option or a 411 (one loaded with -i) it recognizes that there is no way the user running the program can overwrite the text part. It then sets up to use UNIX's shared text mechanism. When the program is loaded and it doesn't already exist on the swap device, it makes a place for both the text part and the user's writable data part in swap space. On each subsequent execution (if the swap image for this program is still there) it makes a place only for the user's data image. Dinking with the memory management, there is only one copy of the text part of any one shared text program in memory (and one on the swap disk) at a time. All user's use their own data part but share the text image. To exploit this even further some programs (noticeably, some shells) have modify their assembler code to cause read-only data to be assembled into text space (of course this only works with -n files and not -i). The reason you can't unlink the inode that is in use, is that the way it knows that your 410 or 411 file is the same as one already running is that it has the inode and disk device numbers stored in an internal structure. If it were to allow you to remove a file that is already running shared text, you could replace the file with the same inode/device combination and it would run that with new data but the old text. The ISVTX (or sticky) bit in the inode (designated by a 't') in ls output, causes shared text programs not to be chucked out of swap space when they are done running. This allows faster startup because it only once ever has to load in the text. -Ron
guy@rlgvax.UUCP (06/15/83)
Actually, the reason that you can't unlink an executable shared-text image
which is running is that if you did, there would be an inode out there
which would have no directory entry pointing to it; if the system crashed,
you would have an unreferenced inode out there and would have to say 'y' to
"fsck".
An inode is freed on disk by "ifree", which is only called from "iput", the
routine which removes a reference to an in-core inode. If the link count on
the inode is zero, AND the reference count drops to zero, the inode is
freed by calling "ifree", setting the mode to 0, and freeing all the blocks.
However, for an active shared-text image, the reference count is NOT zero
until the last process using that image exits. Therefore, the inode won't
be freed until the last process running it exits, and even if the file were
unlinked and a new file put in its place, there wouldn't be any real problems;
any processes executing the new file will get the new image, and the processes
which executed the old file will hold on to the old image. This may cause
some confusion, but it won't wedge the system; and if you're careful about
installing new programs, or if you don't care, it's not a problem. The
inability to remove running programs is a nuisance, and 4.1BSD disabled the
code that forbids it, which is very nice if you're working on a program that
other people are using and you want to stick a new one in and get rid of
the old one.
Note that the SAME "problem" mentioned with a crash up there can be caused
by opening a file, unlinking it, and holding it open; the file won't go away
until the last close, which decrements the reference count to zero.
The information about why unlinking executable images are forbidden comes from
a "highly regarded source" within Bell Labs.
Guy Harris
RLG Corporation
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy