Subject: RE: [nfsv4] re: Out of Sync

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 17 Sep 2003 08:54:44 -0700

Rick wrote:
> If the concensus is to change this, the White Paper could clarify the
> meaning of "each transition of the stateid" in Sec. 2.2 and
> "current locking state" in Sec. 8.1.3, 2nd bullet item on Pg. 70 to change
> it.

OK.  Let's look at the language in question and see if we can do what we
want while staying within the realm of clarification, whether this is done
in a white paper or in editorial corrections to the spec.

So in section 2.2, it says:

> The starting value of the seqid field is undefined.
> The server is required to increment the seqid field monotonically at
> each transition of the stateid.  

I think we can clarify here by saying "A stateid transition may occur
when an open is done on a file already open with that same open_owner
(open upgrade case) or an OPEN_DOWNGRADE is done.  A server may deal
with these cases without effecting a state transition by simply 
returning the existing stateid, including seqid and opaque part
unmodified".  This does not mandate the simpler behavior but I don't
think that would really be a clarification and we can put that off
to v4.1, if we decide that that change is desirable.

> This is important since the client
> will inspect the seqid in OPEN stateids to determine the order of
> OPEN processing done by the server.

I'd like to delete this, unless somebody can figure out what it means
and why the client can't determine the order of processing, even in 
the case in which he has multiple outstanding sequenced requests for
the open_owner, by simply looking at the open_owner seqid order of 
the requests.  I don't know if simply deleting this fits within 
the IETF's definition of "clarification" but deleting something that
doesn't make sense sure makes the text clearer :-)

Now let's go to 8.1.3:

>  o  The stateid was generated by the current server instance but the
>     stateid no longer designates the current locking state for the
>     lockowner-file pair in question (i.e., one or more locking
>     operations has occurred). 

I think it would be clearer to rewrite the parenthetical material as
"(i.e. or more locking operations has caused a transition of the stateid, 
bumping the seqid value within it)"

>     The error NFS4ERR_OLD_STATEID should be returned.

>     This error condition will only occur when the client issues a
>     locking request which changes a stateid while an I/O request that
>     uses that stateid is outstanding.

"changes a stateid" --> "results in a transition of the stateid". 

These would make it clear that not invalidating the stateid is something
the server may choose to do.  Allowing the server to do the invalidating 
looks like something we are stuck with until 4.1.  Since it seems pretty
easy for server not to invalidate and clients would like that better, I
don't expect many servers to take that approach, at least for very long. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, September 17, 2003 10:58 AM
To: [email-masked]
Subject: [nfsv4] re: Out of Sync

My server is in the same boat as the rest. It increments the seqid in the
stateid when the share/deny bits are changed and returns NFS4ERR_OLDSTATEID
if the seqid in the stateid isn't the current one, but could easily be
changed.

If the concensus is to change this, the White Paper could clarify the
meaning of "each transition of the stateid" in Sec. 2.2 and
"current locking state" in Sec. 8.1.3, 2nd bullet item on Pg. 70 to change
it.

In the meantime, my server will probably get a flag that enables/disables
checking for NFS4ERR_OLDSTATEID.

rick

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

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

---

From: Trond Myklebust <[email-masked]>
Date: 17 Sep 2003 12:18:14 -0400

Note: the texts describing the use of NFS4ERR_OLD_STATEID should be
clarified too. Currently those texts only talk about locking state.

Cheers,
  Trond