Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!doc.ic.ac.uk!uknet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: File Truncation Philosophy Message-ID: <1993Apr13.200714.14166@cs.few.eur.nl> Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <1993Apr8.002028.2376@fcom.cc.utah.edu> <1993Apr8.025858.22137@uvm.edu> <1993Apr11.035322.19610@fcom.cc.utah.edu> <C5FJx6.o5w@ns1.nodak.edu> Date: Tue, 13 Apr 1993 20:07:14 GMT Lines: 52 In <C5FJx6.o5w@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes: >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). Isn't the VM system already equipped to handle this? Remember that an executable is mapped MAP_COPY, meaning that any write to one of the pages results in a copy being made (ok, dumb approach, since the copies wind up being backed by the swap pager). One requirement for this to work is that the VM system and the buffer cache be civil to eachother. Adding a field to the vnode structure looks very much the same to me as the "shadow object" field in VM objects. Also, how are we going to detect that a particular (part of) a file is going to be used as text? Suppose I map in a file using mmap(2), then (perhaps some time later) mark it as executable using mprotect. Do you propose that VM code "calls back" to the vnode-layer to inform it of the current status of the address range as being currently executed? Off hand, I would say that would be a step back in the direction of the not-so-modular monoliths. BTW. I am currently trying to debug a particularly nasty case of deadlock involving just such a mix of mmap() and mprotect() (and truncate(), but I think that one is solved now). It looks like the interaction between the vnode- and VM system can use some ironing. >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. I very much second the idea of merging VM and buffer cache subsystems. It should be one the prime targets. I am prepared to have a serious look at it. -pk