From owner-freebsd-hackers  Tue Aug 22 06:56:23 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id GAA26137
          for hackers-outgoing; Tue, 22 Aug 1995 06:56:23 -0700
Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id GAA26124
          for <hackers@freebsd.org>; Tue, 22 Aug 1995 06:56:05 -0700
From: FreeBSD@net-tel.co.uk
Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id OAA16135; Tue, 22 Aug 1995 14:55:11 +0100
X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; 
        Relayed; Tue, 22 Aug 95 14:54:38 +0100
X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";
         Relayed; Tue, 22 Aug 95 13:54:36 +0000
X400-Received: by "/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"; Relayed; 
        Tue, 22 Aug 95 14:53:38 +0100
X400-MTS-Identifier: 
        ["/PRMD=Net-Tel/ADMD=Gold 400/C=GB/";hst:24317-950822135338-5F1D]
X400-Content-Type: P2-1984 (2)
X400-Originator: FreeBSD@net-tel.co.uk
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Tue, 22 Aug 95 14:53:38 +0100
Content-Identifier: Re: Making a Fre
Message-Id: <"hst:24317-950822135338-5F1D*/S=FreeBSD/O=NET-TEL Computer
 Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
To: (Terry Lambert) <terry@cs.weber.edu>
Cc: hackers@freebsd.org
Subject: Re: Making a FreeBSD NFS server
Reply-To: Andrew.Gordon@net-tel.co.uk
Sender: hackers-owner@freebsd.org
Precedence: bulk

> 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).