Subject: [nfsv4] Stateid Structure in draft-12

From: Benny Halevy <[email-masked]>
Date: Tue, 17 Jul 2007 16:57:33 +0300

Spencer, the text added in draft-12 to section 8.1.3.1 about
incrementing seqid looks syntactically weird to me....

  8001	   below, the NFSv4.1 specification requires the server to increment
  8002	   seqid field by one (1) whenever it returns a stateid with an "other"
  8003	   field on that is different that that of the previous stateid it
                 ^^                     ^n^? 
  8012	   generated for the state owner/file combination.  The purpose of the

But, in the next paragraph it says:

  8028	   In the case of stateids associated with opens, i.e. the stateids
  8029	   returned by OPEN (the state for the open, rather than that for the
  8030	   delegation), OPEN_DOWNGRADE, or CLOSE, the server MUST provide an
  8031	   "seqid" value starting at one for the first use of a given "other"
  8032	   value and incremented by one with each subsequent operation returning
  8033	   a stateid.

Doesn't that contradict the text on lines 8000-8012?
What am I missing?

Benny

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 17 Jul 2007 10:30:35 -0400

I don't think you are missing anything.  This issue has been recently
discussed back and forth and I think we have come to a resolution but
the text has not been correctly updated and as it stands now is
inconsistent.

So here is what I think we have agreed on:

    Seqids are used to distinguish any difference in the sets
    of locks designated by a particular "other" value (I think
    we different word than that).  The server must send a seqid
    of one on the creation of a stateid with a new other value
    that represents some set of locks with a given ownership
    status and file.

    When there is a change in that set of locks (different 
    byte ranges and/or upgrade/downgrade) but the file and
    ownership status is the same, then the server must send
    back a stateid with the same other value and seqid 
    incremented by one.

    The client may send to the server a stateid with a 
    specific owner value and the seqid set to zero.  (This
    would typically be done for READ and WRITE).  In this
    case, this designates the current stateid corresponding
    to that other value, no matter what the seqid.

    The client may also send to server a stated with a 
    non-zero seqid value in which case the server checks 
    that that is the most recent seqid for the given other
    value.  (This is typically used for CLOSE).  If the 
    seqid is lower than the current value OLD_STATEID is
    returned while if it is higher than the current value,
    BAD_STATEID is returned.

    There need to be a set of rules about whether current 
    stateid is gotten with zero seqid ot not.  My current
    version of that is that for CLOSE it has the seqid set
    while for anything else it substitutes zero.  Anybody
    have any operations where they think the seqid should
    be propagated?

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 9:58 AM
To: Spencer Shepler
Cc: NFSv4
Subject: [nfsv4] Stateid Structure in draft-12

  8001	   below, the NFSv4.1 specification requires the server to
increment
  8002	   seqid field by one (1) whenever it returns a stateid with an
"other"
  8003	   field on that is different that that of the previous stateid
it
                 ^^                     ^n^? 
  8012	   generated for the state owner/file combination.  The purpose
of the

  8028	   In the case of stateids associated with opens, i.e. the
stateids
  8029	   returned by OPEN (the state for the open, rather than that
for the
  8030	   delegation), OPEN_DOWNGRADE, or CLOSE, the server MUST
provide an
  8031	   "seqid" value starting at one for the first use of a given
"other"
  8032	   value and incremented by one with each subsequent operation
returning
  8033	   a stateid.

Benny