Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!aardvark.ucs.uoknor.edu!ns1.nodak.edu!plains.NoDak.edu!tinguely Newsgroups: comp.os.386bsd.development Subject: Re: File Truncation Philosophy Message-ID: <C5FJx6.o5w@ns1.nodak.edu> From: tinguely@plains.NoDak.edu (Mark Tinguely) Date: Tue, 13 Apr 1993 16:17:30 GMT Sender: usenet@ns1.nodak.edu (Usenet login) References: <1993Apr8.002028.2376@fcom.cc.utah.edu> <1993Apr8.025858.22137@uvm.edu> <1993Apr11.035322.19610@fcom.cc.utah.edu> Organization: North Dakota State University Nntp-Posting-Host: plains.nodak.edu Lines: 41 Terry's suggestion are very interesting. If we need to run copies of a program then here possible alternatives to rewriting the VM to handle the old text copies in the swap (especially when the default swap partition is only 5 Megs). the dumb approach. Once the file starts executing, fail writes to the file. Though this is extremely simple, it is dumb because once opened successfully, writes should not fail. Also Terry points out EBUSY is not POSIX compliant. better (than the dumb) approach. When a program wants to execute an already open file (again as Terry said preferably a writable open file) or open a executable file, copy the file as a temporary in the filesystem. By adding a new vnode reference to the the vnode structure, we can allow other programs that also start executing the now open file, to use this copy of the program (so we do not fill the filesystem with these temporaries). We have two choices of the life time of the temporary (assume the original write lasts longer than the running of the program), we can keep the lifetime of the temporary until we close the write. In this way we keep the file closer to the original and cut down in the copying overhead (in a sense you could think of this like the old days when programs were copied to swap and used the sticky bit). On the other hand we could make the temporary disappear with the last use and if it gets executed several time, a new copy is made (just like normal execute). Obviously if the temporary executes longer than the write, the temporary will stay around until the program finishes. I think appropriate approach is closing the file after all the copies of executing programs have ended and creating a new one if needed. When this thread was started, I was thinking we would have to implement this temporary file approach. Do we lose anything by this temporary in the filesystem versus in the VM (swap/memory)? Speedup. As far as Terry's comments on needing cache changes in the VM for increased performance, I think, Bill Jolitz said, a long time ago, the major changes from 386bsd 0.1 to 0.2 will in VM speedups. If anyone wants to confirm what VM changes has already been/are being made this regard would help the duplication of work.