RFC Errata
Found 10 records.
Status: Verified (9)
RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003
Note: This RFC has been obsoleted by RFC 7530
Source of RFC: nfsv4 (wit)
Errata ID: 2613
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
When an OPEN is done and the specified lockowner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same lockowner.
It should say:
When an OPEN is done and the specified owner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same owner.
Notes:
The 'lockowner' should be replaced by 'owner' (twice in the paragraph). The lockowner is not related to the OPEN operation. Instead, the owner (open_owner) is related.
Errata ID: 2614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the OPEN operation from which the open_confirm value was obtained. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
It should say:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the previous OPEN operation. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
Notes:
The OPEN operation does not return the open_confirm value.
Errata ID: 2637
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current lock, open, or delegation state for any files
and have not been used recently.
It should say:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current open state for any files
and have not been used recently.
Notes:
A lock can be held on already opened files only. This means that every lock state can exist only in case the accompanied open state is already there.
So if there is a lock state held by server then there must be an open state for the file too. This means that we do not need to mention the "current lock state" in the RFC's sentence above.
Next, the delegation state is allocated only in case the delegation is granted by server to a client for a file. The delegation state is related to file and client. It is not related/tied to openowner. This means that it is not possible to test whether an openowner have any delegation states. Delegation states are simply not related to the openowner.
It is easily possible to have a client with some delegation granted with no valid openowner held by a server.
Errata ID: 2663
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-12-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 8.11. says:
When an OPEN is done for a file and the lockowner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
It should say:
When an OPEN is done for a file and the open_owner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
Notes:
The file opens are related to open_owners, not lockowners. The lockowner
should be replaced by open_owner in the first sentence of the paragraph above.
Errata ID: 255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Bauman
Date Reported: 2004-02-03
Section 8.1.8. says:
This sequence establishes the use of an lock_owner and associated sequence number. Should be "a lock_owner"
It should say:
If server replica or a server immigrating a filesystem agrees to Should be "If a server replica"
Notes:
In Section 9.3.2. Data Caching and File Locking, Last Paragraph:
by flushing to the server more data upon an LOCKU than is covered by
the locked range.
Should be "a LOCKU"
Errata ID: 2609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.11. says:
SYNOPSIS
(cfh) locktype, offset, length owner -> {void, NFS4ERR_DENIED ->
owner}
It should say:
SYNOPSIS
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner}
Notes:
Missing comma in the LOCKT synopsis.
Errata ID: 2610
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, open_confirm, attrset delegation
It should say:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, attrset, delegation
Notes:
i) The open_confirm should be removed (it is not a part of the OPEN4resok structure).
ii) There is missing command between attrset and delegation.
Errata ID: 2638
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).
It should say:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN).
Notes:
The FH4_NO_EXPIRE_WITH_OPEN should be replaced with FH4_NOEXPIRE_WITH_OPEN.
Errata ID: 2639
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOL_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOL_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOL_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
It should say:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOLATILE_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
Notes:
The FH4_VOL_ANY should be replaced with FH4_VOLATILE_ANY (three times).
Status: Held for Document Update (1)
RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003
Note: This RFC has been obsoleted by RFC 7530
Source of RFC: nfsv4 (wit)
Errata ID: 3376
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kanda Motohiro
Date Reported: 2012-10-10
Held for Document Update by: Martin Stiemerling
Section 9.6 says:
modified attributes may be returned to the server in the response to a CB_RECALL call.
It should say:
modified attributes may be returned to the server in the response to a CB_GETATTR call.