Date: Tue, 22 Aug 95 14:53:38 +0100 From: FreeBSD@net-tel.co.uk To: (Terry Lambert) <terry@cs.weber.edu> Cc: hackers@freebsd.org Subject: Re: Making a FreeBSD NFS server Message-ID: <"hst:24317-950822135338-5F1D*/S=FreeBSD/O=NET-TEL Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
next in thread | raw e-mail | index | archive | help
> Since I could have two clients, and the server crashed, then the state > has to be reinstantiated by both clients. > > Consider that if I have client 1 with a lock outstanding and client 2 > with a lock request outstanding and blocked on client 1's lock, if > client 2 begins crash recovery prior to client 1, it will assert its > outstanding lock request -- which the server will grant, not having > client 1's context to use as a wakeup address. Actually, the existing NFS lock protocol can handle this, provided that the implementor of the client lockd has thought about this combination. New lock requests are refused during the grace period immediately following reboot, allowing the clients notified by statd to get their old locks back in before any new locks are granted. To get it right in your example, client 2 has to regard the ountstanding-but-not-yet-granted lock as a different category from established locks - it does need to be reclaimed in response to the crash notification from the server, but should be retried as an ordinary lock request rather than a reclaim (and so will be bounced until the end of the grace period).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"hst:24317-950822135338-5F1D*/S=FreeBSD/O=NET-TEL Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/">