RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 34 records.

Status: Verified (16)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 2291

Status: Verified
Type: Technical

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

Section 18.36.3. says:

      The server
      MUST specify an ONC RPC program number equal to csa_cb_program and
      an ONC RPC version number equal to 4 in callbacks sent to the
      client.

It should say:

      The server
      MUST specify an ONC RPC program number equal to csa_cb_program and
      an ONC RPC version number equal to 1 in callbacks sent to the
      client.

Notes:

RFC5661 disagrees with RFC5662. The latter specifies a version number of 1.

Errata ID: 2005

Status: Verified
Type: Technical

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

Section 15.1.11.3 says:

The highest_slot argument in a Sequence operation exceeds the replier's enforced
highest_slotid.

It should say:

The highest_slot argument in a Sequence operation exceeds the replier's enforced
highest_slotid. Also, the rsa_target_highest_slotid argument in a CB_RECALL_SLOT
operation exceeds maximum enforced slot ID of the session's fore channel.

Notes:

The NFSv4.1 specification permits the client to return NFS4ERR_BAD_HIGH_SLOT in
the event rsa_target_highest_slotid is higher the highest slot ID of the
session's fore channel. Arguably this is an unnecessary complication; the client
can return NFS4_OK to sucvh a CB_RECALL_SLOT operation, and then send a
SEQUENCE operation with an sa_highest_slotid argument that is less than or
equal to rsa_target_highest_slotid. NFSv4.2 should specify this simplification.

Errata ID: 2299

Status: Verified
Type: Technical

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

Section 18.45.3. says:

If SECINFO_STYLE4_PARENT is passed, then
   SECINFO_NO_NAME is querying for the required security of the current
   filehandle's parent

It should say:

If SECINFO_STYLE4_PARENT is passed, then
   SECINFO_NO_NAME is querying for the required security of the current
   filehandle's parent, where the current filehandle MUST be that of directory (an object of type NF4DIR).

Errata ID: 2326

Status: Verified
Type: Technical

Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.16.3 says:

NFS4ERR_NXIO (Error Code 5) 

It should say:

NFS4ERR_NXIO (Error Code 6) 

Errata ID: 2327

Status: Verified
Type: Technical

Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 6.4.3.1 says:

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_FLAG is set.

It should say:

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_ACE is set.

Errata ID: 3208

Status: Verified
Type: Technical

Reported By: Benny Halevy
Date Reported: 2012-05-02
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Throughout the document, when it says:


Notes:

Section 12.5.2. says:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.

It should say:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.
| The client MUST serialize LAYOUTGET operations using a non-layout
| stateid with any other operation affecting the layout state on the file,
| including CB_LAYOUTRECALL, to allow consistent initialization of the
| layout state.

Add the following paragraph to section 12.5.3.:
| A client MAY always forget its layout state and associated
| layout stateid at any time (See also section 12.5.5.1).
| In such case, the client MUST use a non-layout stateid for the next
| LAYOUTGET operation. This will signal the server that the client has
| no more layouts on the file and its respective layout state can be
| released before issuing a new layout in response to LAYOUTGET.

Section 12.5.5.2.1. says:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding, the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.

It should say:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding,
| or if the client has a outstanding LAYOUTGET with a non-layout stateid,
the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.

Section 12.5.5.2.1.1. says:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.

It should say:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file
| using the layout stateid
or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.

Section 12.5.5.2.1.2. says:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded;

It should say:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded,
| or the client has an outstanding LAYOUTGET using a non-layout stateid;

Errata ID: 3558

Status: Verified
Type: Editorial

Reported By: Cal Turney
Date Reported: 2013-03-19
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-20

Section 15.1.4.2 says:

In Table 5 Section 5.1 Page 342, NFS4ERR_DQUOT is defined as error number 69:

    "| NFS4ERR_DQUOT | 69 | Section 15.1.4.2 |"

However, in Section 15.1.4.2 Page 349 it is identified as error code 19:

    "15.1.4.2. NFS4ERR_DQUOT (Error Code 19)"

It should say:

    "15.1.4.2. NFS4ERR_DQUOT (Error Code 69)"


Notes:

I believe NFS4ERR_DQUOT is in fact 69 and the reference to error code 19 in Section 15.1.4.2 is a typo.

In RFC 3010, Error Code 19 was assigned to "NFS4ERR_NODEV" but that association appears to have suffered the same fate as RFC 3010 itself and there is no mention of NFS4ERR_NODEV in RFC 3530 which rendered that RFC obsolete.

Errata ID: 2006

Status: Verified
Type: Editorial

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.

Errata ID: 2062

Status: Verified
Type: Editorial

Reported By: Peter Varga
Date Reported: 2010-03-04
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 2.10.6.1.3 says:

A reply that consists only of the Sequence operation with the error NFS4ERR_FALSE_RETRY.

When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY...

If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_FALSE_RETRY.

...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_FALSE_RETRY...

The difference is due to NFS4ERR_FALSE_RETRY being a valid error for only Sequence operations...

It should say:

A reply that consists only of the Sequence operation with the error NFS4ERR_SEQ_FALSE_RETRY.

When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_SEQ_FALSE_RETRY...

If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_SEQ_FALSE_RETRY.

...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_SEQ_FALSE_RETRY...

The difference is due to NFS4ERR_SEQ_FALSE_RETRY being a valid error for only Sequence operations...

Notes:

References to NFS4ERR_FALSE_RETRY instead of NFS4ERR_SEQ_FALSE_RETRY

Errata ID: 2249

Status: Verified
Type: Editorial

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

Section 12.5.5.2.1.5 says:

   Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST
   NOT allow the client to use any layout stateid that refers to a file
   with the specified fsid except for LAYOUTCOMMIT operations.  Once the
   client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_ALL, it MUST NOT
   use any layout stateid that refers to a file with the specified fsid
   except for LAYOUTCOMMIT operations.

It should say:

   Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST
   NOT allow the client to use any layout stateid that refers to a file
   with the specified fsid except for LAYOUTCOMMIT operations.  Once the
   client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID, it MUST NOT
   use any layout stateid that refers to a file with the specified fsid
   except for LAYOUTCOMMIT operations.

Notes:

Copy/paste error from the previous paragraph. s/_ALL/_FSID/ in the second sentence of the corrected paragraph.

Errata ID: 2280

Status: Verified
Type: Editorial

Reported By: Paul J Gilliam
Date Reported: 2010-05-20
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 10.4 says:

   OPEN_DELEGATE_READ delegations may be outstanding simultaneously and
   do not conflict.  An OPEN_DELEGATE_WRITE delegation allows the client
   to handle, on its own, all opens.  Only OPEN_DELEGATE_WRITE
   delegation may exist for a given file at a given time, and it is
   inconsistent with any OPEN_DELEGATE_READ delegations.

It should say:

   OPEN_DELEGATE_READ delegations may be outstanding simultaneously and
   do not conflict.  An OPEN_DELEGATE_WRITE delegation allows the client
   to handle, on its own, all opens.  Only one OPEN_DELEGATE_WRITE
   delegation may exist for a given file at a given time, and it is
   inconsistent with any OPEN_DELEGATE_READ delegations.

Errata ID: 2324

Status: Verified
Type: Editorial

Reported By: Trond Myklebust
Date Reported: 2010-07-12
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 2.10.6.2 says:

A retry might be sent while the original request is still in progress
on the replier.  The replier SHOULD deal with the issue by returning
NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but
implementations MAY return NFS4ERR_MISORDERED.

It should say:

A retry might be sent while the original request is still in progress
on the replier.  The replier SHOULD deal with the issue by returning
NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but
implementations MAY return NFS4ERR_SEQ_MISORDERED.

Errata ID: 2328

Status: Verified
Type: Editorial

Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 15.1.16 says:


Notes:

From 3530:

NFS4ERR_RESOURCE For the processing of the COMPOUND procedure, the server may exhaust available resources and can not continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.

Since it is not used by 5661, shouldn't it appear in Section 15.1.16 Obsoleted Errors?

Errata ID: 2330

Status: Verified
Type: Editorial

Reported By: Tom Haynes
Date Reported: 2010-07-14
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 3.3.7 says:

   0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

It should say:

                     0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

Errata ID: 2548

Status: Verified
Type: Editorial

Reported By: J. Bruce Fields
Date Reported: 2010-10-11
Verifier Name: Lars Eggert
Date Verified: 2011-03-07

Section 18.36.3 says:

csa_fore_chan_attrs, csa_fore_chan_attrs:

It should say:

csa_fore_chan_attrs, csa_back_chan_attrs:

Errata ID: 4215

Status: Verified
Type: Editorial

Reported By: Tom Haynes
Date Reported: 2014-12-30
Verifier Name: Martin Stiemerling
Date Verified: 2016-02-02

Section 22.1 says:

   All assignments to the registry are made on a First Come First Served
   basis, per Section 4.1 of [55].  The policy for each assignment is
   Specification Required, per Section 4.1 of [55].

It should say:

The registry is to be maintained using the Specification Required
policy as defined in Section 4.1 of [55].

Notes:

Found during the IANA Review of 3530bis.

Status: Reported (10)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 2505

Status: Reported
Type: Technical

Reported By: Michael Eisler
Date Reported: 2010-08-31

Section 12.5.4. says:

   Because of this inconsistency, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is required.

It should say:

   Because of this inconsistency, in general, it is necessary to resynchronize the
   client with the metadata server and its storage devices and make any
   potential changes available to other clients. 

AND

   For file-based layouts, synchronization of
   attributes between the metadata and storage devices, primarily the
   size attribute, is not required, but the use of LAYOUTCOMMIT provides 
   a way to optimize the synchronization. Indeed, if a LAYOUT4_NFSV4_1_FILES
   layout is ever revoked, the metadata server MUST direct all data servers to
   commit any modified data of the file to stable storage, and synchronize 
   the file's size and time_modify attributes on the metadata server
   with the those on the data server.

Notes:

Without this correction, the implication is that a file could be truncated if a LAYOUT4_NFSV4_1_FILES layout was revoked before LAYOUTCOMMIT, which would then mean that every append operation to a data server would require a LAYOUTCOMMIT, which is an absurd consequence.

Errata ID: 2751

Status: Reported
Type: Technical

Reported By: Ricardo Labiaga
Date Reported: 2011-03-21

Throughout the document, when it says:


It should say:

12.5.4.1.  LAYOUTCOMMIT and change/time_modify
becomes
12.5.4.2.  LAYOUTCOMMIT and change/time_modify


12.5.4.2.  LAYOUTCOMMIT and size
becomes
12.5.4.3.  LAYOUTCOMMIT and size


12.5.4.3.  LAYOUTCOMMIT and layoutupdate
becomes
12.5.4.4.  LAYOUTCOMMIT and layoutupdate


Add new Section 
12.5.4.1 Implications of LAYOUTCOMMIT on file layouts
For file layouts, WRITEs to a Data Server that return a stable_how4 value of 
FILE_SYNC4 guarantee that data and file system metadata are on stable 
storage.  This means that a LAYOUTCOMMIT is not needed in order to make the 
data and metadata visible to the metadata server and other clients.

For file layouts, when WRITE to the data server returns UNSTABLE4 or 
DATA_SYNC4  and the NFL4_UFLG_COMMIT_THRU_MDS flag is set, the client MUST 
send the COMMIT to the metadata server.  A successful COMMIT to the metadata 
server guarantees that data and file system metadata are on stable storage.  
Therefore, any time that NFS4_UFLG_COMMIT_THRU_MDS is set, a LAYOUTCOMMIT (of 
the byte range specified by the layout) is not needed.

For file layouts, when NFL4_UFLG_COMMIT_THRU_MDS flag is not set, and WRITE or 
COMMIT to the data server return DATA_SYNC4, the client MUST send the 
LAYOUTCOMMIT to the metadata server in order to synchronize file metadata.  

The following table summarizes the rules when a LAYOUTCOMMIT is needed, and 
the effects of a COMMIT to a data server and metadata server.  

+------------+------------+------------+------------+----------+
| NFL4_UFLG_ | WRITE to   | Meaning of | Meaning    | LAYOUT   |
| COMMIT_    | DS returns | COMMIT to  | of COMMIT  | COMMIT   | 
| THRU_MDS   |            | DS         | to MDS     | required |            
+------------+------------+------------+------------+----------+
| Not Set    | UNSTABLE4  | DATA_SYNC4 | Nothing    | Yes      |
| Not Set    | DATA_SYNC4 | Nothing    | Nothing    | Yes      |
| Not Set    | FILE_SYNC4 | Nothing    | Nothing    | NO       |
| Set        | UNSTABLE4  | Nothing    | FILE_SYNC4 | NO       |
| Set        | DATA_SYNC4 | Nothing    | FILE_SYNC4 | NO       |
| Set        | FILE_SYNC4 | Nothing    | Nothing    | NO       |
+------------+------------+------------+------------+----------+

Note that a client can always demand FILE_SYNC4 or DATA_SYNC4 in WRITE's 
arguments.  Also note that specifying these stability levels may adversely 
impact performance.

If a LAYOUTCOMMIT is required, it should be sent before CLOSE to maintain 
close-to-open semantics.  If required, it should be sent before LOCKU, 
OPEN_DOWNGRADE, LAYOUTRETURN, and when the application issues fsync() [25].  
Again, if LAYOUTCOMMIT is required, it should be sent periodically to keep the 
file size and modification time synchronized.  This allows use cases like 
tail -f [56] which copies its input file to the standard output and updates 
the output as new lines become available in the input file.  It is up to the 
client implementation to determine how frequently LAYOUTCOMMIT is issued.  
Possible policies include every N'th COMMIT to a data server, every N'th unit 
of time, or after writing a stripe to a set of data servers.

Even if a required LAYOUTCOMMIT is not issued by the client, the data server 
and metadata servers have a set of responsibilities to fulfill in order to 
guarantee data consistency:
1) Data servers MUST commit data and synchronize modification and size 
attributes with the metadata server before a layout is revoked as described in 
section 12.5.4.
2) Data servers SHOULD commit data and synchronize modification and size 
attributes with the metadata server after the metadata server reboots.  In 
theory the client should commit the data, but this avoids the problem where 
both the client and metadata server crash at the same time.
3) The metadata server MAY periodically poll data servers to synchronize 
modification and size attributes.


Section 13.9.2.3 says:
   For the NFSv4.1-based data storage protocol, it is  necessary to re-
synchronize state such as the size attribute, and  the setting of 
mtime/change/atime.

Should say:
   For the NFSv4.1-based data storage protocol, it may be necessary to re-
synchronize state such as the size attribute, and the setting of 
mtime/change/atime.


Section 13.10 says:
   For the case above, this means that a LAYOUTCOMMIT will be done at close 
(along with the data WRITEs) and will update the file's size and change 
attribute.

Should say:
   For the case above, this means that, if necessary, a LAYOUTCOMMIT will be 
done at close (along with the data WRITEs) and will update the file's size and 
change attribute.


Section 18.3.4 says:
   The COMMIT operation is similar in operation and semantics to the POSIX 
fsync() [25] system interface that synchronizes a file's state with the disk 
(file data and metadata is flushed to disk or stable storage).  COMMIT 
performs the same operation for a client, flushing any unsynchronized data and 
metadata on the server to the server's disk or stable storage for the 
specified file.

Should say:
   The COMMIT operation is similar in operation and semantics to the POSIX 
fsync() [25] system interface that synchronizes a file's state with the disk 
(file data and metadata is flushed to disk or stable storage).  COMMIT 
performs the same operation for a client, flushing any unsynchronized data and 
metadata on the server to the server's disk or stable storage for the 
specified file.  When using pNFS, if a WRITE returned UNSTABLE4 and 
NFL4_UFLG_COMMIT_THRU_MDS is not set, then the client MUST COMMIT to the data 
server.  The COMMIT may result in flushing the data but not the metadata.  In 
this case, the metadata MUST be flushed with a subsequent LAYOUTCOMMIT to the 
metadata server.  A complete set of pNFS rules for flushing data and metadata 
is described in section 12.5.4.1.


Section 18.3.4 says:
   The above description applies to page-cache-based systems as well as buffer-
cache-based systems.  In the former systems, the virtual memory system will 
need to be modified instead of the buffer cache.

Should say:
   The above description applies to page-cache-based systems as well as buffer-
cache-based systems.  In the former systems, the virtual memory system will 
need to be modified instead of the buffer cache.

   Refer to Section 12.5.4.1 for a discussion of the effects of data stability 
levels on data servers or metadata servers.


Section 18.32.4 says:
   However, since it is possible for a WRITE to be done with a special 
stateid, the server needs to check for this case even though the client should 
have done an OPEN previously.

Should say:
   However, since it is possible for a WRITE to be done with a special 
stateid, the server needs to check for this case even though the client should 
have done an OPEN previously.

   Refer to Section 12.5.4.1 for a discussion of the effects of data stability 
levels on data servers or metadata servers.


Section 20.3.4 says:
   In the case of modified data being written while the layout is held, the 
client must use LAYOUTCOMMIT operations at the appropriate time; as required 
LAYOUTCOMMIT must be done before the LAYOUTRETURN.

Should say:
   In the case of modified data being written while the layout is held, the 
client may be required to use LAYOUTCOMMIT operations at the appropriate time; 
if LAYOUTCOMMIT is required, it must be done before the LAYOUTRETURN.


Add new informative reference to Section 23.2
[56] The Open Group, "section 'tail' of The Open Group Base Specifications 
Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), 
ISBN 1931624453, 2004.


Notes:

A new section describing the implications of LAYOUTCOMMIT on file layouts is
defined in this errata, along with updates to existing sections of the spec.
The technical details in this errata were agreed upon at the IETF Interim
Meeting in Sunnyvale, CA on Feb 18-19, 2011.

Errata ID: 3379

Status: Reported
Type: Technical

Reported By: Asmita Karandikar
Date Reported: 2012-10-15

Section 18.50.3 says:

If there are
sessions (both idle and non-idle), opens, locks, delegations, 
layouts, and/or wants (Section 18.49) associated with the unexpired 
lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.

It should say:

If there are 
sessions (both idle and non-idle), opens, locks, delegations, 
and/or wants (Section 18.49) associated with the unexpired 
lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.

Notes:

Should not include layouts.
A forgetful client may not return LAYOUTS. In this case, a server will always return NFS4ERR_CLIENTID_BUSY on DESTROY_CLIENTID and end up persisting the client’s lease until it expires although the client is explicitly asking us not to.

Errata ID: 3714

Status: Reported
Type: Technical

Reported By: Yuri Radchenko
Date Reported: 2013-08-31

Section 13.4.4. says:

The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util
of the data type nfsv4_1_file_layouthint4 and field nfl_util of data
type nfsv4_1_file_layout_ds_addr4)

It should say:

The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util
of the data type nfsv4_1_file_layouthint4 and field nfl_util of data
type  nfsv4_1_file_layout4)

Notes:

nfsv4_1_file_layout_ds_addr4 data type does not have field nflh_util

Errata ID: 3901

Status: Reported
Type: Technical

Reported By: Trond Myklebust
Date Reported: 2014-02-25
Edited by: Martin Stiemerling
Date Edited: 2015-12-16

Section 18.43.3 says:

The logr_return_on_close result field is a directive to return the
layout before closing the file.  When the metadata server sets this
return value to TRUE, it MUST be prepared to recall the layout in the
case in which the client fails to return the layout before close.
For the metadata server that knows a layout must be returned before a
close of the file, this return value can be used to communicate the
desired behavior to the client and thus remove one extra step from
the client's and metadata server's interaction.

It should say:

The logr_return_on_close result field is a directive to return
or forget the layout when the client returns all open/delegation
state for that file.

Once a LAYOUTGET operation returns with logr_return_on_close
set to TRUE for a given file, then all subsequent LAYOUTGET
requests by that client for the same file and layout type, MUST
reply with logr_return_on_close set to TRUE until the client returns
all its open state for that file using CLOSE and DELEGRETURN.
Note that return_on_close also applies retroactively to all layout
segments retrieved by the client for that file and layout type.

After the client has closed all open stateids and returned the
delegation stateids for a file for which logr_return_on_close
was set to TRUE, the server MUST  invalidate all layout segments
that were  issued to the client for that file. The client MUST NOT
attempt to use that layout or the layout stateid.

If the server needs to revoke all open stateids and delegation
stateids owned by the client for a file for which logr_return_on_close
was set to TRUE, then it MUST also revoke all layout segments of 
type loga_layout_type that were issued for that file to that client, 
and take action to fence the access to the DSes.

Notes:

This is intended as a replacement for the errata with id 3226, which is incomplete in that it does not discuss how return-on-close is supposed to work with delegations or with layout revoking.
--VERIFIER NOTES--
Please get an agreement in the WG and submit an up to date errata, as this text part seems to be under discussion.

2016-06-17: RFC Editor moved from Rejected to Reported per request from AD (Spencer Dawkins).

Errata ID: 4119

Status: Reported
Type: Technical

Reported By: Christoph Hellwig
Date Reported: 2014-09-17

Section 12.2.10 says:

A device ID lives as long as there is a layout referring to the
device ID.  If there are no layouts referring to the device ID, the
server is free to delete the device ID any time.

It should say:

A device ID is established by referencing it in the result of a
GETDEVICELIST or LAYOUTGET operation and can be deleted by the server
as soon as there are no layouts referring to the device ID.

If the client requested notifications for device ID mappings, the
server SHOULD send CB_NOTIFY_DEVICEID notifications for device ID
deletions or changes to the device-ID-to-device-address mappings to any
client which has used the device-ID in question at least once,
irrespective of whether the client has any layouts currently referring
to it. If the server does not support or the client does not request
notifications for device ID mappings, the client SHOULD periodically
retired unused device IDs.


Given that GETDEVICELIST does not support requesting notifications a
server that implements GETDEVICELIST MUST not not advertise support
for NOTIFY_DEVICEID4_CHANGE notification in GETDEVICEINFO, and client
using GETDEVICELIST must not rely on NOTIFY_DEVICEID4_CHANGE or
NOTIFY_DEVICEID4_DELETE notifications to work reliably.

Notes:

The lifetime rules in RFC5661 are contradictory - both GETDEVICELIST and CB_NOTIFY_DEVICEID (NOTIFY4_DEVICEID_DELETE) operations imply that device IDs are valid even without layouts referring to them. Implementations rely on this fact by caching not referenced device IDs to avoid the huge setup costs, and thus require notifications to be sent for that case.

Errata ID: 4492

Status: Reported
Type: Technical

Reported By: David Noveck
Date Reported: 2015-10-05

Section 18.17.4 says:

If the server does not support named attributes for the current 
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the 
client.

It should say:

If the server does not support named attributes for file system 
objects on the file system associated with the current filehandle, 
an error of NFS4ERR_NOTSUPP will be returned to the client.

Notes:

There are a number of situations in which, a server might not support named attributes on particular file system objects. A number of cases concern doing an OPENATTR on a named attribute directory or named attribute and are mentioned in the immediately preceeding section.
Aside from that contradiction, many implementations might allow named attributes on
symbolic likes or special files. The existing text would require NFS4ERR_NOTSUPP rather
than NFS4ERR_WRONG_TYPE to be returned in such cases, causing the client to conclude
incorrectly that named attribute support is not present for the file system in question, or at
least be uncertain about the presence/absence of such support.

Errata ID: 4711

Status: Reported
Type: Technical

Reported By: Tom Haynes
Date Reported: 2016-06-16

Section 15.1.5.5 says:

A stateid with a non-zero seqid value does match the current seqid
   for the state designated by the user.

It should say:

A stateid with a non-zero seqid value is not the most current seqid
   for the state.

Notes:

Two issues here:

1) The negation of the fact, i.e., "does not match".
2) The state is not associated with an user.

Errata ID: 4712

Status: Reported
Type: Technical

Reported By: Trond Myklebust
Date Reported: 2016-06-16

Section 6.2.1.3.1. says:

   ACE4_DELETE

      Operation(s) affected:

         REMOVE

It should say:

   ACE4_DELETE

      Operation(s) affected:

         REMOVE

         RENAME

Notes:

ACE4_DELETE on the source file may allow a rename to proceed in cases where the user does not have ACE4_DELETE_CHILD on the source directory. It may also affect the ability of the user to be able to RENAME if there is an existing file in the target directory with the target name.

Errata ID: 4572

Status: Reported
Type: Editorial

Reported By: Sai Chakravarthy Tangudu
Date Reported: 2015-12-30

Section 18.35.3 says:

A server MUST NOT use the same client ID for two different
incarnations of an eir_clientowner.

It should say:

A server MUST NOT use the same client ID for two different
incarnations of an eia_clientowner.

Status: Held for Document Update (7)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 3065

Status: Held for Document Update
Type: Technical

Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.7.4 says:

      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the data (as described by the loca_offset,
      loca_length, and loca_layoutupdate fields of the arguments) that
      was written to the storage device. If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client has lost all the data in the range
      defined by <loca_offset, loca_length>.  

It should say:

      If the metadata server's
      consistency checks on loca_layoutupdate succeed, then the metadata
      server MUST commit the changed data that was written to the storage
      device within the scope of the LAYOUTCOMMIT operation.
      If the metadata server's
      consistency checks on loca_layoutupdate fail, the metadata server
      rejects the LAYOUTCOMMIT operation and makes no changes to the
      file system.  However, any time LAYOUTCOMMIT with loca_reclaim
      TRUE fails, the pNFS client may have lost all uncommitted
	data within the scope of the failed LAYOUTCOMMIT operation.  

Notes:

Errata 2 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3066

Status: Held for Document Update
Type: Technical

Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.7.4 says:

   o  The client does not have a copy of the data in its memory and the
      metadata server is no longer in its grace period; i.e., the
      metadata server returns NFS4ERR_NO_GRACE.  As with the scenario in
      the above bullet point, the failure of LAYOUTCOMMIT means the data
      in the range <loca_offset, loca_length> lost.  The defense against
      the risk is the same -- cache all written data on the client until
      a successful LAYOUTCOMMIT.

It should say:

   o  The client does not have a copy of the data in its memory and the
      metadata server is no longer in its grace period; i.e., the
      metadata server returns NFS4ERR_NO_GRACE.  As with the scenario in
      the above bullet point, the failure of LAYOUTCOMMIT means the data
      in the scope of that LAYOUTCOMMIT may have been lost.  The defense
      against the risk is the same -- cache all written data on the client
      until a successful LAYOUTCOMMIT.

Notes:

Errata 3 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3067

Status: Held for Document Update
Type: Technical

Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 18.42.3 says:

   The LAYOUTCOMMIT operation commits changes in the layout represented
   by the current filehandle, client ID (derived from the session ID in
   the preceding SEQUENCE operation), byte-range, and stateid.  Since
   layouts are sub-dividable, a smaller portion of a layout, retrieved
   via LAYOUTGET, can be committed.  The byte-range being committed is
   specified through the byte-range (loca_offset and loca_length).  This
   byte-range MUST overlap with one or more existing layouts previously
   granted via LAYOUTGET (Section 18.43), each with an iomode of
   LAYOUTIOMODE4_RW.  In the case where the iomode of any held layout
   segment is not LAYOUTIOMODE4_RW, the server should return the error
   NFS4ERR_BAD_IOMODE.  For the case where the client does not hold
   matching layout segment(s) for the defined byte-range, the server
   should return the error NFS4ERR_BAD_LAYOUT.

It should say:

   The LAYOUTCOMMIT operation commits changes in the layout represented
   by the current filehandle, client ID (derived from the session ID in
   the preceding SEQUENCE operation), and stateid.  As a layout-independent
   operation, LAYOUTCOMMIT commits the entire layout; layout type-specific
   data (loca_layoutupdate) may specify a smaller scope of data that is to
   be committed (e.g., for the block layout, see RFC 5663 [41]).

   The loca_offset and loca_length arguments have been deprecated.  The
   client SHOULD set both loca_offset and loca_length to 0.
   The server MUST ignore the loca_offset and loca_length arguments.
   The client MUST hold one or more existing layouts
   previously granted via LAYOUTGET (Section 18.43), with an iomode of
   LAYOUTIOMODE4_RW.  If layout type-specific data (loca_layoutupdate)
   restricts the scope of the LAYOUTCOMMIT to less than the entire layout,
   the client MUST hold one or more existing layouts with an iomode
   of LAYOUTIOMODE4_RW fully covering the committed byte ranges.
   In the case where no previously granted layout
   has an iomode of LAYOUTIOMODE4_RW, the server should return the error
   NFS4ERR_BAD_IOMODE.  For the case where the client does not hold
   any previously granted layout, the server should return the error
   NFS4ERR_BAD_LAYOUT.

Notes:

Errata 4 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3068

Status: Held for Document Update
Type: Technical

Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 18.42.3 says:

   The loca_last_write_offset field specifies the offset of the last
   byte written by the client previous to the LAYOUTCOMMIT.  Note that
   this value is never equal to the file's size (at most it is one byte
   less than the file's size) and MUST be less than or equal to
   NFS4_MAXFILEOFF.  Also, loca_last_write_offset MUST overlap the range
   described by loca_offset and loca_length. 

It should say:

   The loca_last_write_offset field specifies the offset of the last
   byte written by the client previous to the LAYOUTCOMMIT.  Note that
   this value is never equal to the file's size (at most it is one byte
   less than the file's size) and MUST be less than or equal to
   NFS4_MAXFILEOFF.

Notes:

Errata 5 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 4118

Status: Held for Document Update
Type: Technical

Reported By: Christoph Hellwig
Date Reported: 2014-09-17
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 20.12.3 says:

NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which if TRUE indicates that the change will
  be enforced immediately, and so the client might not be able to
  complete any pending I/O to the device ID.  If ndc_immediate is
  FALSE, then for an indefinite time, the client can complete
  pending I/O.  After pending I/O is complete, the client SHOULD get
  the new device-ID-to-device-address mappings before sending new
  I/O requests to the storage devices addressed by the device ID.

It should say:

NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which SHOULD be ignored by the client.
  The client may finish any outstanding I/Os that reference the
  previously provided device-ID-to-device-address mapping and SHOULD
  use GETDEVICEINFO to obtain the updated mapping for the previously
  provided device-ID-to-device-address mapping before requesting new
  layouts.  All outstanding layouts remain valid after a notification
  of type NOTIFY_DEVICEID4_CHANGE.  If the device-ID-to-device-address
  mapping changed in an incompatible way that would invalidate
  outstanding layouts, the server MUST recall all outstanding layouts
  and send a NOTIFY_DEVICEID4_DELETE notification instead.

Notes:

Clarify what DEVICEID4_CHANGE means vs layouts instead of I/Os. Drop the under specified ndc_immediate flag, which can't be enforced.

Errata ID: 3064

Status: Held for Document Update
Type: Editorial

Reported By: David Black
Date Reported: 2011-12-27
Held for Document Update by: Martin Stiemerling

Section 12.5.4 says:

   The LAYOUTCOMMIT operation is responsible for committing a modified
   layout to the metadata server.  The data should be written and
   committed to the appropriate storage devices before the LAYOUTCOMMIT
   occurs.  The scope of the LAYOUTCOMMIT operation depends on the
   storage protocol in use.

It should say:

   The LAYOUTCOMMIT operation is responsible for committing a modified
   layout to the metadata server.  The data should be written and
   committed to the appropriate storage devices before the LAYOUTCOMMIT
   occurs.  The scope of data committed by a LAYOUTCOMMIT operation is
   specific to the type of layout because that scope depends on the
   storage protocol in use.

Notes:

Errata 1 of 5 to deprecate loca_offset and loca_length arguments to LAYOUTCOMMIT.

Errata ID: 3653

Status: Held for Document Update
Type: Editorial

Reported By: Kanda Motohiro
Date Reported: 2013-06-15
Held for Document Update by: Martin Stiemerling
Date Held: 2016-02-02

Section 13.4.2 says:

The destinations of the first 13 storage units are:

It should say:

The destinations of the first 13 stripe units are:

Notes:

Same errata on Section 13.4.3

Status: Rejected (1)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 2722

Status: Rejected
Type: Editorial

Reported By: Ricardo Labiaga
Date Reported: 2011-02-15
Rejected by: Lars Eggert
Date Rejected: 2011-02-16

Section 15.2 says:

   | ILLEGAL              | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL         |
   | LAYOUTCOMMIT         | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |

It should say:

   |                      | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL         |
   | LAYOUTCOMMIT         | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |

Notes:

ILLEGAL is not an operation. The errors belong to GETFH, the previous operation listed.
--VERIFIER NOTES--
Submitter wishes to retract the errata.

Report New Errata



Search RFCs
Advanced Search
×