[nfsv4] Re: seqids after changing slot table size

[Trond Myklebust <[e-mail]>]

On Mon, 2024-12-09 at 10:29 +1100, NeilBrown wrote:
> On Sat, 16 Nov 2024, David Noveck wrote:
> > 
> > 
> > I'm convinced.  The next draft of rfc5661bis will address this
> > issue.
> > 
> 
> Hi,
>  I would like to offer some thoughts on how this issue could be
>  addressed.
> 
>  The issue is that retiring of DRC slots is mentioned in the RFC but
>  details are scarce.  It is not clear whether or when either peer can
> be
>  sure that that the other has retired a slot, or exactly what that
>  means.  It *is* clear on some cases where the peer *cannot* retire a
>  slot.

The spec is very clear on how the client and server agree on whether or
not a slot has been retired.

   1. In the reply to any SEQUENCE op, the server sets the
      sr_target_highest_slotid to the value of the largest slot id that
      it wants the client to aim for. Additionally, it may or may not
      actually send a CB_RECALL_SLOT callback operation.
   2. Once the client is done with a slot, it starts to lower the value
      of sa_highest_slotid in the SEQUENCE op arguments in order to
      inform the server that it is completely done, and will not send
      any further requests (including replays) to that slot.
   3. Once the server sees that value of sa_highest_slotid in a
      SEQUENCE op (on a slot for which the sr_target_highest_slotid was
      also set to the new value in a preceding reply), it adjusts the
      value of sr_highest_slotid returned in the replies to the
      SEQUENCE ops to tell the client that the slot is actually
      retired.

All this is documented in RFC8881 in section 2.10.6.1.


-- 
Trond Myklebust Linux NFS client maintainer, Hammerspace
[e-mail]