RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020

Errata ID: 8022
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ed Schouten
Date Reported: 2024-07-08

Section 8.2.2 says:

   In making comparisons between seqids, both by the client in
   determining the order of operations and by the server in determining
   whether the NFS4ERR_OLD_STATEID is to be returned, the possibility of
   the seqid being swapped around past the NFS4_UINT32_MAX value needs
   to be taken into account.  When two seqid values are being compared,
   the total count of slots for all sessions associated with the current
   client is used to do this.  When one seqid value is less than this
   total slot count and another seqid value is greater than
   NFS4_UINT32_MAX minus the total slot count, the former is to be
   treated as lower than the latter, despite the fact that it is
   numerically greater.

It should say:

Whatever was stated in RFC 7530 (NFSv4.0), section 9.1.3.

Notes:

The number of slots has no relationship with the maximum drift a seqid value may have:

- A single COMPOUND request could contain many operations that cause the seqid to change. For example, one could craft a single COMPOUND request with many of no-op OPEN_DOWNGRADEs that each increment the seqid.

- Imagine a session with two slots. One slot is used in a tight loop to repeatedly invoke OPEN on many different paths, which unbeknownst to the client all refer to the same (hardlinked) file. If the other slot is used to call CLOSE against the same file, it is not unlikely that the difference between the seqid becomes larger than two.

Report New Errata