From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ronald G Minnich To: <9fans@cse.psu.edu> Subject: Re: [9fans] Ephase question. In-Reply-To: <931d6696b6f862f8f9f7aaf1cde0bf8b@plan9.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 13 Aug 2002 09:53:44 -0600 Topicbox-Message-UUID: dc0e5c68-eaca-11e9-9e20-41e7f4b1d025 On Tue, 13 Aug 2002 presotto@plan9.bell-labs.com wrote: > My biggest headache has been replacing running binaries. Since we > can't remove them or overwrite them without disasterous consequences, > we end up with a 'safeinstall' option in all our mkfiles. The safeinstall > moves the file to an unlikely name (e.g. x -> _x) and copies in the > new file. Of course, since we have dozens of machines all running off > the same file system, something is probably running off the _x that > was there. So we sometimes have to move _x to __x, etc. It's a > royal pain. yes, NFS has a similar problem with this but in a different place. When clients remove files, NFS servers don't really remove files, they rename them. See SILLYRENAME. In NFS servers never know if someone is using a file, so they don't want to remove it, hence all that .nfsxxyyzzww crud you start to see in NFS over time (if the rm happens on client). Of course if the rm happens on server, and a remote process is exec'ing the file, bad things happen. This latter problem has led people over the years to do the same kind of thing you describe above. Or, as in one place I worked, the sysadmins upgrade executables on the server and then reboot everybody's machine. > We often forget and just install with the result that > someone an hour after the fact in some other part of the building > sends you a snap or pointer to a broken process. Since I don't have > to implement the fs, I'ld have preferred the Unix semantics in this > case. It's caused me a lot of inconvenience over the last 10+ years. I've just got v9fs back and mostly working on Linux (uses 9p still but 3e ... 4e is next). But I'm going to have the Unix semantics. The shared exec over a network case is too common not to use the Unix semantics. ron