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'..."