Subject: Early end of grace period

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 6 Dec 1999 14:40:19 -0800

I've been working on the spec changes to split up and
clarify the various errors that can occur when stateid's
aren't valid based on 
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1851.html.
I'm now figuring out what to do about section 8.5.2
(in draft-02), in which NFS4ERR_GRACE is now being 
superseded for many purposes by NFS4ERR_DEADSTATE,
which allows you to detect stateid's from old server
instances, in or out of the grace period.

Given this change, the servers have the opportunity 
to be a little more flexible with the grace period
while still providing safe recovery.  As the spec
is written right now, NFS service is basically
unavailable during the grace period since IO, as
well as locking requests cannot be done at all
until the grace period is over.

It occurs to me that in many cases, servers will be able
to safely resume (at least partial) service before the 
full grace period is over.  First, if server knows that
all of the locks for a given file have been reclaimed
(as it might by storing some lock information, like counts,
in stable storage) there is no point in continuing to reject 
other locking requests, and so the grace period (for a 
particular file) might well be terminated early.  The 
server should have this flexibiity, since for actively 
used files, the clients will be doing IO, will quickly 
find out about the reboot, and will recover their locks
quickly and will want to be able to do something.  Note 
that allowing this will enable servers to set large lease 
periods without essentially causing the server to be 
effectively dead for long periods after coming up.  

Also, once a lock has been reclaimed, the fresh stateid
can be distinguished from an old one (which will get
NFS4ERR_DEADSTATE) and thus could be validly used, 
when the server knows that any potentially unreclaimed
lock could not invalidate the IO being done.  For instance,
if a file is not subject to mandatory locking or if the
server knows that there are no unreclaimed record locks
for the file (a common case), it could allow IO to proceed
by those who had reclaimed their opens, without waiting
for everyone to reclaim their opens.  

So what I'm leaning to is that,

      NFS4ERR_DEADSTATE reports server reboots to the client.

      NFS4ERR_GRACE is defined as reporting that the operation
      in question (locking or IO) cannot be processed because 
      there may be state to be reclaimed by clients (during 
      a grace period) and that the reclaimed state may invalidate
      the current request.

This requires the server to give NFS4ERR_GRACE for locking
whenever there might be an unreclaimed lock that would interfere.
For IO it would have to give NFS4ERR_GRACE if there might be
any unreclaimed lock which, when reclaimed would prevent the
IO from being processed.  A simple implementation could return
NFS4ERR_GRACE for any locking or IO during the grace period
that didn't result in NFS4ERR_DEADSTATE, but servers would be
free to be more creative while still maintaining safe recovery.

Unless anybody knows why this won't work or us otherwise a 
bad idea, this is the way I'm going to revise section 8.5.2.