Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!wupost!decwrl!pa.dec.com!e2big.mko.dec.com!peavax.mlo.dec.com!paik From: paik@mlo.dec.com (Samuel S. Paik) Subject: Re: File Truncation Philosophy Message-ID: <1993Apr3.210730.1543@peavax.mlo.dec.com> Sender: usenet@peavax.mlo.dec.com (USENET News System) Organization: Digital Equipment Corporation, Alpha Personal Systems Software Group References: <C4tJ6C.C17@ns1.nodak.edu> <1pfteb$ch5@umd5.umd.edu> Date: Sat, 3 Apr 1993 21:07:30 GMT Lines: 39 In article <1pfteb$ch5@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes: >Idea 4: Copy the program text into the swap area > 4a- always. This causes a performance penalty when you start a > program. > 4b- when executing from a filesystem not known to be "reliable". > NFS. CDFS is unlikely to be a problem. various other > ideas here (e.g. 1,4c) might make UFS reliable. It would > probably work best if you had the kernel be conservative > about any "new" filesystem types. e.g. you don't know if > marksfs does what you need or not. > 4c- when the program file is opened for writing. You would have > to block the open until the copy was complete. I'm not certain you can do 4c with NFS. I don't like the idea of 4b (embedding knowledge of some, but not all, fs in the kernel). 4a, of course, is what used to happen... >Idea 5: When writing to an executing file, remove the block you are writing > to from the file. (Give it to some other file, so it stays allocated.) > allocate a new block to do the write in. This is "copy-on-write" for > file blocks. Interesting idea, sounds like one of the Amoeba file systems intended for write-once media. >Some combinations of these would produce a system like what you wanted. >(I caution that #3 and #5 look like they will cause more pain than they >prevent.) It seems to me that it is time to rethink BSD FS semantics. A general solution, that I've mentioned before, is to include REAL file locks, shared and exclusive. This of course requires some revision of the file system interface and semantics. (And makes NFS look even more broken than it is already...) Sam Paik p.s. Anyone ready for QuickSilver yet?