Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!sdcsvax!ucsdhub!esosun!seismo!uunet!munnari!vuwcomp!duncan From: duncan@vuwcomp.UUCP Newsgroups: comp.unix.wizards Subject: Stateless NFS with Record Locking (was: //host vs "mount point") Message-ID: <13107@comp.vuw.ac.nz> Date: Thu, 3-Dec-87 20:41:39 EST Article-I.D.: comp.13107 Posted: Thu Dec 3 20:41:39 1987 Date-Received: Wed, 9-Dec-87 00:48:18 EST References: <38c15248.4580@hi-csc.UUCP> <6759@brl-smoke.ARPA> Reply-To: duncan@comp.vuw.ac.nz (Duncan McEwan) Organization: Comp Sci, Victoria Univ, Wellington, New Zealand Lines: 17 Summary: How do they do it? In article <6759@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >Fundamentally, NFS remains stateless. Last I heard, the locking was >being done by arrangement with external daemons. (It is actually record >locking, in support of SVID requirements, not just whole-file locking.) How do Sun make this work? If a locking daemon is running on a machine that crashes then that daemon loses track of what files are locked. If a client crashes, how does the locking daemon know to unlock files that it had locked? As Doug says, with the locking done by external daemons, the NFS protocol itself remains stateless, but I can't see how you still don't lose the benifits of it's statelessness. Duncan "The America's Cup -- why wait until 1991...?" Domain: duncan@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan