errata logo graphic

Found 10 records.

Status: Verified (9)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 2613

Status: Verified
Type: Technical

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

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

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

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

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

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

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

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

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)

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

Source of RFC: nfsv4 (tsv)

Errata ID: 3376

Status: Held for Document Update
Type: Technical

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.

Report New Errata