From: Spencer Shepler (shepler@eng.sun.com)
Date: 08/19/98-03:39:52 PM Z
Date: Wed, 19 Aug 1998 15:39:52 -0500 (CDT) From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Questioning one of the anticipated core features of NFSv4 (Fwd) Message-ID: <Roam.SIMC.2.0.6.903559192.30313.shepler@eng.sun.com> Bounced on first try. >----------------Begin Forwarded Message----------------< Date: Wed, 19 Aug 1998 15:04:34 -0500 From: dwd@ihgp.ih.lucent.com Subject: Re: Questioning one of the anticipated core features of NFSv4 To: nfsv4-wg@sunroof.eng.sun.com On Aug 18, 7:22pm, Brent.Callaghan@eng.Sun.COM wrote: > > My second priority is to be able to update a program that is running on an > > NFS client without crashing the running program. Currently, on local > > filesystems or even on a single NFS client, one can unlink a running > > program file and it will not get completely deleted until the last > > invocation of the program exits. This doesn't work when a program is > > running on one client and the file is unlinked on another client or on the > > server, because the NFS server has no way of knowing that a client is still > > using the program; instead, when the file is replaced with a new one and > > the client program needs some other page it just crashes. Has this problem > > been solved in any of the research networked filesystems? Probably the > > problem should be generalized to any open file on a client, not just > > running programs. > > Putting a lock on the file probably wouldn't be looked upon > kindly by a sysadmin trying to update the file on the server. Do you mean that a lock would prevent an rm (unlink) from removing a file from a directory? > A smart sysadmin will rename the file before installing the > new version and leave the old, renamed version around for > a while. A stupid sysadmin will "cp" the new version over > the top of the old one :-) I'm thinking of automated remote updates, where we first unlink all the old files and then install the new ones under the same names. > The problem gets a little stickier where the application > consists of a "package" of files that must all be of > the same version. Our sysadmins install the packages > with the public name as a symbolic link that points > to the latest version. The old versions are kept around > with version suffixes on the names. I'm familiar with that technique, and I wonder if this NFS deficiency is the main reason they go through all that trouble. There are other advantages of course, of being able to back out to a previous version, or of continuing to support a long-running executable, but it seems to be overkill for most cases. It certainly would be expensive in disk space for our situation, where we've got lots of software replicated on many hundreds of servers. > Back to the original problem. The impact of an executable > changing on the server could be reduced if the client had > a large enough disk cache. The entire executable could then > be cached without the risk of pieces of it being paged out > and the cached version could be "held" if the client's OS > detects that the file is open or being executed. I haven't > used AFS but I believe it works in a similar way. We > can disk cache with NFS too. Doesn't that assume that the entire executable would have been paged in at least once? What if only part of it is paged in, and later on another piece is needed (after it has been updated)? - Dave Dykstra >----------------End Forwarded Message----------------<
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:11 AM Z CST