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