RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010

Note: This RFC has been obsoleted by RFC 8881

Note: This RFC has been updated by RFC 8178, RFC 8434

Source of RFC: nfsv4 (wit)
See Also: RFC 5661 w/ inline errata

Errata ID: 2006
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Eisler
Date Reported: 2010-01-17
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.1.3 says:

For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The client should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up client resources such as a
   session slot.  After delaying for period of time, the client can then
   re-send the operation in question (but not with the same slot ID and
   sequence ID; one or both MUST be different on the re-send).

   Note that without the ability to return NFS4ERR_DELAY and the
   client's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

It should say:

For any of a number of reasons, the replier could not process this
   operation in what was deemed a reasonable time.  The requester should
   wait and then try the request with a new slot and sequence value.

   Some examples of scenarios that might lead to this situation:

   o  A server that supports hierarchical storage receives a request to
      process a file that had been migrated.

   o  An operation requires a delegation recall to proceed, and waiting
      for this delegation recall makes processing this request in a
      timely fashion impossible.

   In such cases, the error NFS4ERR_DELAY allows these preparatory
   operations to proceed without holding up requester resources such as a
   session slot.  After delaying for period of time, the requester can then
   re-send the operation in question. If the operation that returned
   NFS4ERR_DELAY was not a Sequence operation, the initial, preceding 
   Sequence operation of the Compound request MUST NOT be re-sent with same 
   slot ID and sequence ID; one or both MUST be different on the re-send. If
   the operation that returned NFS4ERR_DELAY was a Sequence operation, then
   the Sequence MUST be re-sent with the same slot ID and sequence ID.

   Note that without the ability to return NFS4ERR_DELAY and the
   requester's willingness to re-send when receiving it, deadlock might
   result.  For example, if a recall is done, and if the delegation
   return or operations preparatory to delegation return are held up by
   other operations that need the delegation to be returned, session
   slots might not be available.  The result could be deadlock.

Notes:

This errata is correcting two problems:

(1) The use of term "requester" instead of "client" since NFS4ERR_DELAY
is applicable for both the backchannel and fore channel.

(2) Clarification that NFS4ERR_DELAY from a Sequence operation is handled
differently from non-Sequence operations.

Report New Errata



Advanced Search