Skip site navigation (1)Skip section navigation (2)
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: <http://docs.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/">