Subject: [nfsv4] Proposal for errata to RFC5661

From: Trond Myklebust <[email-masked]>
Date: Fri, 26 Sep 2014 20:08:26 -0400

Section 8.4.3 says:
   o  a boolean that indicates whether the client may have locks that it
      believes to be reclaimable in situations in which the grace period
      was terminated, making the server's view of lock reclaimability
      suspect.  The server will set this for any client record in stable
      storage where the client has not done a suitable RECLAIM_COMPLETE
      (global or file system-specific depending on the target of the
      lock request) before it grants any new (i.e., not reclaimed) lock
      to any client.

It should say:

   o  a timestamp that is updated the first time after a server boot or reboot
      when the client acquires byte-range locking, share reservation, or
      delegation state on the server, or upon receiving a suitable
      RECLAIM_COMPLETE (global or file system-specific depending on the
      target of the lock request).

Section 8.4.3 says:

   For the second edge condition, after the server restarts for a second
   time, the indication that the client had not completed its reclaims
   at the time at which the grace period ended means that the server
   must reject a reclaim from client A with the error NFS4ERR_NO_GRACE.

   When either edge condition occurs, the client's attempt to reclaim
   locks will result in the error NFS4ERR_NO_GRACE.  When this is
   received, or after the client restarts with no lock state, the client
   will send a global RECLAIM_COMPLETE.  When the RECLAIM_COMPLETE is
   received, the server and client are again in agreement regarding
   reclaimable locks and both booleans in persistent storage can be
   reset, to be set again only when there is a subsequent event that
   causes lock reclaim operations to be questionable.

It should say:

   For the second edge condition, after the server restarts for a second
   time, the lack of a timestamp indication that the client did indeed establish
   reclaimable state in the previous boot instance means that the server must
   reject a reclaim from client A with the error NFS4ERR_NO_GRACE.

   When either edge condition occurs, the client's attempt to reclaim
   locks will result in the error NFS4ERR_NO_GRACE.  When this is
   received, or after the client restarts with no lock state, the client
   will send a global RECLAIM_COMPLETE.  When the RECLAIM_COMPLETE is
   received, the server and client are again in agreement regarding
   reclaimable locks. The server can then set the timestamp, and reset
   the boolean in persistent storage.

Notes:
As it reads now, the spec appears to state that in the second edge
condition case, the locks that were reclaimed by client A after the
initial server reboot should not be reclaimed after the second reboot.
There is no reason why they shouldn't, since those locks are not
contested by any other clients.

The real issue in the second edge condition is that both client A and
the server need to agree whether or not lock state was held by client
A during the period between the first and second reboot. Once that
agreement has been established, then client A has full knowledge of
which locks were held, and it can therefore attempt to recover only
those locks.