Subject: [nfsv4] Pending changse for spec

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 17 Feb 2008 13:10:01 -0500

The following includes some fixes previously discussed, together with
some clarifications and additional detail regarding the "seqid" field in
stateids and issues related to having multiple stateid's for the same
file and lockowner (because the openowners are different):

Index: nfsv41_middle_core_infrastructure.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_core_infrastructure.xml,v
retrieving revision 1.83
diff -r1.83 nfsv41_middle_core_infrastructure.xml
2098c2098
<      Givem that well formulated XIDs continue to be required,
---
>      Given that well formulated XIDs continue to be required,
2107c2107,2108
<      guarantee the re-association of a reply with its request (<xref
target="rpc_xid_issues" />); having
---
>      guarantee the re-association of a reply with its request
>      (<xref target="rpc_xid_issues" />); having
Index: nfsv41_middle_filelocking.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_filelocking.xml,v
retrieving revision 1.43
diff -r1.43 nfsv41_middle_filelocking.xml
230c230,232
<       the initial lock.  It
---
>       the initial lock, or a range that consists of a range which
>       overlaps, fully or partially, that initial lock or a
>       combination of a set of existing locks for the same lock owner.
It
275a278,332
>   <section title="Stateid Seqid Values and Byte-range Locks"
>            anchor="byte_range_seqid" >
>     <t>
>       When a lock or unlock request is done, passing a stateid,
>       the stateid returned has the same "other" value and a
>       "seqid" value that is incremented to reflect the occurrence
>       of the lock or unlock request.  The server MUST increment
>       the value of the "seqid" field whenever there is any change
>       to the locking status of any byte offset as described by
>       any of locks covered by the stateid.  A change in locking
>       status includes a change from locked to unlocked or the reverse
or
>       a change from being locked for read to being locked for write
>       or the reverse.
>     </t>
>     <t>
>       When there is no such change, as, for example
>       when a range already locked for write is locked again
>       for write, the
>       server MAY increment the "seqid" value.
>     </t>
>   </section> <!-- "Stateid Sequence Values and Byte-range Locks" -->
>   <section title="Issues with Multiple Open-owners"
>            anchor="multiple_openowners" >
>     <t>
>       When the same file is opened by multiple open-owners and
>       there are LOCK and LOCKU requests for the same lock-owner
>       issued through the different open files, a situation may
>       arise in which there are multiple stateids representing
>       byte-range locks for locks on the the same file held by
>       the same lock-owner but each assigned to a different
>       open-owner.
>     </t>
>     <t>
>       In such a situation, the locking status of each byte
>       (i.e. whether it is locked, the read or write mode of
>       the lock and the lock-owner holding the lock) MUST
>       reflect the last LOCK or LOCKU operation done for the
>       lock-owner in question, independent of the stateid through
>       which the request was issued.
>     </t>
>     <t>
>       When a byte is locked by the lock-owner in question, the
>       open-owner to which that lock is assigned SHOULD be that
>       of the open-owner associated with the stateid through
>       which the last LOCK of that byte was done.  When there
>       is a change in the open-owner associated with locks for
>       the stateid through which a LOCK or LOCKU was done, the
>       "seqid" field of the stateid MUST be incremented, even
>       if the locking, in terms of lock-owners has not changed.
>       When there is a change to the set of locked bytes associated
>       with a different stateid for the same lock-owner, i.e.
>       associated with a different open-owner, the "seqid" value
>       for that stateid MUST NOT be incremented.
>     </t>
>   </section> <!-- "Issues with Multiple Open-owners" -->
414c471,476
<       that of the original open.  Only a single CLOSE
---
>       that of the original open, and whose "seqid" value is
incremented
>       to reflect the occurrence of the upgrade.  The increment is
required
>       in cases in which the
>       "upgrade" results in no change to the open mode (e.g. an OPEN
>       is done for read when the existing open file is opened for
>       read-write).  Only a single CLOSE
441c503,506
<       properly.
---
>       properly.  The stateid returned has the same "other" field as
>       that passed to the server.  The "seqid" value in the returned
>       stateid MUST be incremented, even is situation in which there is
>       no change the access and deny bits for the file.
Index: nfsv41_middle_op_create.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_create.xml,v
retrieving revision 1.10
diff -r1.10 nfsv41_middle_op_create.xml
29,33c29,34
<       The objname specifies the name for the new object.  The objtype
<       determines the type of object to be created: directory, symlink,
etc.
<       If the typename is that of an ordinary file, a named attribute,
<       or a named attribute directory, the error NFS4ERR_WRONG_TYPE
<       results.
---
>       The objname specifies the name for the new object.
>       The objtype determines the type of object to be
>       created: directory, symlink, etc. If the object
>       type specified is that of an ordinary file, a
>       named attribute, or a named attribute directory,
>       the error NFS4ERR_BADTYPE results.
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4