kendall@saber.com (03/22/91)
My application would like to mmap an NFS-mounted file read-only and be guaranteed of the integrity of its data; that is, if someone overwrites the file, I'd like my application to keep seeing the original data. This is for SunOS or SVR4. Of course, this could be implemented by making a copy of the file, but that is too slow and takes up too much disk or swap space. I want mmap's wonderful performance behavior: lazy reading, and no swap space used. My understanding is that what I want is impossible under SVR4. So I'm reluctantly willing to guarantee that only other instances of my application will be anyone trying to overwrite the file, so they can cooperate. This reduces the problem to advisory file locking, more or less. SunOS documents two kinds of file locking. Only one (lockf(3)) is supposed to work across a network, and when I tried reasonable things it hung my processes for a while. From this experience, and from talking to people, I get the feeling that nobody uses lockf because it doesn't work very well. I need this locking to be a reliable service available at all customer sites without much trouble on the customers' part. My questions are: Has anyone made a system that guarantees this behavior? More specifically, is there a reliable advisory file locking service available, either a fixed lockf(3) or a 3rd party equivalent? Any other advice? Please reply by mail. Sam Kendall kendall@Saber.COM Saber Software, Inc. uunet!saber!kendall (617) 876-7636
gdmr@lfcs.edinburgh.ac.uk (George Ross) (03/28/91)
In article <2023@brchh104.bnr.ca> you write: > My application would like to mmap an NFS-mounted file read-only and be > guaranteed of the integrity of its data; that is, if someone overwrites > the file, I'd like my application to keep seeing the original data. This > is for SunOS or SVR4. I can't help you directly, as I didn't ever get round to trying a UNIX implementation (I have a working VMS version, if that's any good 8-)), but you could try something like this: Each "virtual file" comes in two parts. There's a static part, which is only ever updated as a result of a policy decision, and a "differential" part which contains some book-keeping information and copies of any changed pages. When the virtual file is opened those pages in the static part which aren't in the differential part are mapped read-only into your VM, while the differential part is mapped read-write. If you write to the differential part that's fine. If you try to write to the static part you'll get a signal. You field the signal, allocate a new differential page (update the book-keeping information), copy the data and map the differential version read-write in place of the static version. Then return from the signal handler to resume the instruction which caused the signal. You can implement proper transactions using this scheme (that's what we originally used it for) by mapping the differential part read-only in the first instance and allocating new pages when you try to write to it in the same manner as you do for the static part. You can arrange that your transaction is committed by writing one single page of header information, or abandoned by not writing the new header information. Of course, your virtual file can be the static part for some other virtual file, and so on. There's more in my 1983 PhD thesis "Virtual Files: a Framework for Experimental Design". Send mail to dam@cs.ed.ac.uk if you're interested. It's CST-26-83. I believe there's a real-money charge, but I don't know how much. TFS does something similar, so far as I can see. George D M Ross, Department of Computer Science, University of Edinburgh 031-650 5147 Janet: gdmr@uk.ac.ed.cs Internet: gdmr@cs.ed.ac.uk