Search RFCs

RFC Editor

Found 10 records.

Status:Verified (9)

RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003

Note: This RFC has been obsoleted byRFC 7530

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 toShould 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 byRFC 7530

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 responseto a CB_RECALL call.

It should say:

modified attributes may be returned to the server in the responseto a CB_GETATTR call.

Report New Errata