RFC Errata
Found 42 records.
Status: Verified (22)
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)
Errata ID: 2291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
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.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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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: 3379
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Asmita Karandikar
Date Reported: 2012-10-15
Verifier Name: Magnus Westerlund
Date Verified: 2019-10-25
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: 4711
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2016-06-16
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03
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: 5040
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Price
Date Reported: 2017-06-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03
Section 18.46.3 says:
Operations other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID, CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first operation in a COMPOUND.
It should say:
Operations other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID, DESTROY_CLIENTID, CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first operation in a COMPOUND.
Notes:
In the section for DESTROY_CLIENTID (18.50.3), the following text exists (see snipped section below).
This means that DESTROY_CLIENTID must also be in the list for operations that are allowed
in the first operation of a compound.
<...snip...>
If DESTROY_CLIENTID is not prefixed by SEQUENCE, it MUST be the only
operation in the COMPOUND request (otherwise, the server MUST return
NFS4ERR_NOT_ONLY_OP). If the operation is sent without a SEQUENCE
preceding it, a client that retransmits the request may receive an
error in response, because the original request might have been
successfully executed.
<...snip...>
Errata ID: 5467
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2018-08-17
Verifier Name: Spencer Dawkins
Date Verified: 2018-08-17
Section 15.2 says:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
It should say:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
Notes:
LAYOUTGET takes a stateid argument that can represent either a layout or a delegation,
or open/lock state. As such, it needs to be able to report back when the state represented
by that stateid has expired.
(Verified on NFSv4 mailing list)
Errata ID: 6015
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sushil Agarwal
Date Reported: 2020-03-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-04
Section 17 says:
CB_SEQUENCE | OPT
It should say:
CB_SEQUENCE | REQ
Notes:
The section 20.9.3 of CB_SEQUENCE says
"In each CB_COMPOUND request, CB_SEQUENCE MUST appear once and MUST be the
first operation. The error NFS4ERR_SEQUENCE_POS MUST be returned
when CB_SEQUENCE is found in any position in a CB_COMPOUND beyond the
first. If any other operation is in the first position of CB_COMPOUND, NFS4ERR_OP_NOT_IN_SESSION MUST be returned."
Since CB_RECALL_SLOT is REQ operation in NFSv4.1. This make CB_COMPOUND as REQ procedure. Since CB_COMPOUND require CB_SEQUENCE as its first operation and hence CB_SEQUENCE must be required operation.
Errata ID: 3558
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
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.
Errata ID: 2062
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 6324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2020-11-04
Verifier Name: RFC Editor
Date Verified: 2024-02-02
Section 18.23.3 says:
The request's cookieverf field should be set to 0 zero) when the
It should say:
The request's cookieverf field should be set to 0 (zero) when the
Notes:
Missing the open parenthesis
Status: Held for Document Update (17)
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)
Errata ID: 2505
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-08-31
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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: 3065
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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: 3714
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yuri Radchenko
Date Reported: 2013-08-31
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2014-02-25
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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).
2019-10-25: TSV AD Magnus Westerlund put this into the Held for document update so that the WG can deal with the consensus deision issues related to this clarification when updating the document.
Errata ID: 4118
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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: 4119
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Christoph Hellwig
Date Reported: 2014-09-17
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2015-10-05
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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: 4712
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2016-06-16
Held for Document Update by: Magnus Westerlund
Date Held: 2020-09-03
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.
AD notes based on Chuck Lever's input.
o The text in RFC 5661 Section 6.2.1.3.1 matches the text in RFC 7530 Section 6.2.1.3.1. Are updaed of RFC 7530 also needed for this reason?
o Should the Notes section of the errata be added to Section 6.2.1.3.2?
o A consideration is if there are already server implementations that reject RENAME operations in these cases, or do all server implementations permit RENAME?
o This is held so that the issues can be addressed in rfc5661bis after further discussion.
o Additional Editorial correction: The Discussion subsections of ACE4_DELETE and ACE4_DELETE are missing the word "how".
Errata ID: 5212
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: NFS4ERR_ROFS is not a valid error code for LAYOUTGET
Date Reported: 2017-12-19
Held for Document Update by: Magnus Westerlund
Date Held: 2020-09-04
Section 15.2 says:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
It should say:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
Notes:
It could be argued that the OPEN takes care of a NFS4ERR_ROFS for a LAYOUTGET of a LAYOUTIOMODE4_RW, but that does not explain why WRITE is allowed to return a NFS4ERR_ROFS.
With the Flex File Layout Type, the storage device depends on the metadata server enforcing the read-only filesystem semantics. An NFSv3 WRITE to the storage device might be accepted even though the filesystem might be RO. Further, if a snapshot is taken, the storage device might not be aware of the fact that a data file is in a snapshot.
Currently, if the underlying filesystem determines that the LAYOUTGET for a LAYOUTIOMODE4_RW is going to return NFS4ERR_ROFS, to be spec compliant, it MUST convert the error code to NFS4ERR_SERVERFAULT. The client may then decide to perform IO through the metadata server with NFSv4 WRITE calls, which will in turn get a NFS4ERR_ROFS error. This change pushes the responsibility to be on the LAYOUTGET and allows the client to inform the application of an error earlier.
AD Comments:
This topic requires WG discussion and establishment of consensus. Thus for future document update.
--VERIFIER NOTES--
This topic requires WG discussion and establishment of consensus. Thus for future document update.
Errata ID: 3064
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Errata ID: 4572
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sai Chakravarthy Tangudu
Date Reported: 2015-12-30
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
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.
Errata ID: 4914
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dylan Simon
Date Reported: 2017-01-22
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
Section 14.3.3 says:
Mapping Used by nfs4_cis_prep
It should say:
Mapping Used by nfs4_mixed_prep
Notes:
Section header is incorrect, possibly copied from previous section 14.2.3
Errata ID: 5476
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2018-08-23
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25
Section 18.42.3 says:
matching layout segment(s) for the defined byte-range, the server should return the error NFS4ERR_BAD_LAYOUT.
It should say:
matching layout segment(s) for the defined byte-range, the server should return the error NFS4ERR_BADLAYOUT.
Notes:
The error code is NFS4ERR_BADLAYOUT.
Status: Rejected (3)
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)
Errata ID: 2751
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Labiaga
Date Reported: 2011-03-21
Rejected by: Magnus Westerlund
Date Rejected: 2019-10-25
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.
--VERIFIER NOTES--
This errata was rejected based on formal process grounds that Errata is not allowed to change the WG consensus at the time of publication, and also is very extensive. This issue do need to be addressed in an update to the RFC.
Errata ID: 5982
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2020-02-13
Rejected by: Magnus Westerlund
Date Rejected: 2020-09-03
Section 2.10.6.1.3.1 says:
If a requester sent a Sequence operation with a slot ID and sequence ID that are in the reply cache but the replier detected that the retried request is not the same as the original request, including a retry that has different operations or different arguments in the operations from the original and a retry that uses a different principal in the RPC request's credential field that translates to a different user, then this is a false retry. When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY in response to the Sequence operation when it detects a false retry.
It should say:
If a requester sent a Sequence operation with a slot ID and sequence ID that are in the reply cache but the replier detected that the retried request is not the same as the original request, including a retry that was issued with a different XID or has different operations or different arguments in the operations from the original and a retry that uses a different principal in the RPC request's credential field that translates to a different user, then this is a false retry. When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY in response to the Sequence operation when it detects a false retry
Notes:
The existing text can be read as requiring checksumming of all requests to foreclose the possibility of not noticing a false retry, which can result in data corruption. This can be a
significant performance consideraation in the processing of WRITE requests and could undercut the benefits of directly placing data to be written which is one of the impotant goals of RPC-over-RDMA.
--VERIFIER NOTES--
No consensus in the WG if this is just a correction. Thus rejecting the issue and may be brought for WG consenus discussion in the context of document update.
Errata ID: 2722
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.