Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!jade!ucbvax!unisoft!mtxinu!ed
From: ed@mtxinu.UUCP (Ed Gould)
Newsgroups: comp.unix.wizards
Subject: Re: Stateless NFS with Record Locking (was: //host vs "mount point")
Message-ID: <533@mtxinu.UUCP>
Date: Sat, 5-Dec-87 14:22:46 EST
Article-I.D.: mtxinu.533
Posted: Sat Dec  5 14:22:46 1987
Date-Received: Thu, 10-Dec-87 22:21:37 EST
References: <38c15248.4580@hi-csc.UUCP> <6759@brl-smoke.ARPA> <13107@comp.vuw.ac.nz>
Reply-To: ed@mtxinu.UUCP (Ed Gould)
Organization: mt Xinu, Berkeley
Lines: 24

In article <13107@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>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.
>
>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?

There are actually two cooperating daemons: the lock manager and the
status monitor.  They both exist on all machines.  The status monitor
is responsible for notifying the lock manager of client crashes.

There is also a recovery protocol that allows clients to regain
locks if the server crashes.  Before the rebooted server accepts
general lock requests, it accepts lock renewal requests for
a period of time.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
{ucbvax,uunet}!mtxinu!ed    +1 415 644 0146

"`She's smart, for a woman, wonder how she got that way'..."