scs@seismo.CSS.GOV (06/22/87)
Various comments/requests were made about unlinking files, free
space, fifos, and NFS. Since I've had a lot of experience at the
application program level with these, I thought I'd stick in my
$.02...
Unlinking a temporary file and then writing to is a good way of
guaranteeing that the file will automaticly disappear when it is
no longer needed. The drawbacks are:
1. As someone already pointed out, if the process which creates
the tempfile does not die and does not properly delete the file,
it exists effectively forever. It takes up space, but cannot
be found vi du, etc. This is a flaw in the application program,
not the principle.
2. If the system crashes while such a file is open, fsck will report
(and correctly fix) file system errors. I think it finds the
used inode and disk space but no directory entries, bitches
about it, and then fixes it. [[I'm not going to crash a system
just to verify the error message, but that's how I remember it.]]
3. If the tempfile is very large, you can run out of disk space
but not be able to tell where the space all went to. Unfortunately,
one of the better reasons to do this sort of thing is to guarantee
large tempfiles will automaticly get deleted. You pays your money
and you takes your chances.
FIFOs have some similar problems/advantages. We used FIFOs to do
some primitive servers: the server created a publicly writable (but
not readable) FIFO which it did blocking reads on to get requests.
Clients would create their own FIFO which they would make publicly
writable, and hand it's name to the server. When the server responded
on the client's FIFO, the client would delete the FIFO but keep it open.
This guarenteed a secure I/O channel from server to client, and kept
the system clean after crashes (which happened a lot on that particular
system). Here's what we found:
1. Like deleted tempfiles, deleted FIFOs caused fsck to find and
correct errors after crashes. No big deal.
2. FIFOs apparently cannot grow as large as a tempfile before the
writer blocks. While this could cause a server to hang if the
client hung, in practice our messages were short enough for it
not to be a problem. It does avoid the problem with large deleted
FIFOs invisibly using up all your file space.
3. A non-deleted FIFO with data in it when the system crashed does
cause an error in file size which fsck detects and corrects.
Again, I'm not going to crash a system to find out, but as best
I recall the message was about a mismatch between the size noted
in the inode and the actual disk space allocated. Fsck correctly
reset the size in the inode to zero.
Most of these wonderful features can go right out the window if you
don't watch yourself with NFS. Since the use of deletion of files and
sharing of FIFOs depends a lot on use of the disk buffer cache, NFS
can mess you up. Darned if I know if there are even FIFOs permitted
in NFS/Sun UNIX, but if they're gonna be SystemV compatabile they're
going to have to address it. Of course, if you have Suns and sockets
and such you can use other (koff koff) "simpler" "better" ways of
writing servers. I'm just glad that I'm not trying to port that
application...
Removing tempfiles can be a disaster under NFS. If the tempfile is
created in an NFS-mounted file system, removing the file can cause
the file to actually disappear. Writes to and reads from the file
will get errors once you exhaust your use of the disk cache, so you
get the interesting problem of having programs get intermittent and
apparently random errors. Worse, most programs that do this assume
that read(2) and write(2) never fail, and hence quickly shuffle off
to NeverNeverLand. The only way to keep things working right is to
make sure that you open your tempfile in an ND partition -- and ND
partitions often don't leave you much free disk. This is the price
of progress [[ ;-) ]], and it'll be interesting to see what happens
when ND goes away in Sun OS release 4.0.
Steve Simmons
ihnp4!itivax!lokkur!scs
"It's *my* machine, and I'll snub who I want to."guy%gorodish@Sun.COM (Guy Harris) (06/22/87)
> Darned if I know if there are even FIFOs permitted in NFS/Sun UNIX, > but if they're gonna be SystemV compatabile they're > going to have to address it. They are, starting with release 3.2, and they are S5-compatible. They don't buffer data on disk, though. The question of "what happens when you unlink an open file over NFS" was answered by somebody else earlier; if the file is being held open by a process on the same machine, the system notes this fact and renames the file rather than unlinking it. > Of course, if you have Suns and sockets and such you can use other > (koff koff) "simpler" "better" ways of writing servers. Note that one advantage of using sockets - Internet-domain sockets, anyway - is that the client and server need not be on the same machine. > Worse, most programs that do this assume that read(2) and write(2) never > fail... Well, programs shouldn't do that. Disks get I/O errors, network connections time out, file systems fill up, etc., etc.; if this happens, most people would prefer to hear about it rather than simply having programs mysteriously and silently fail. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com