Subject: re: [nfsv4] proposal to make stateid4.seqid transparent

From: [email-masked]
Date: Tue, 22 Aug 2006 15:08:00 -0400 (EDT)

[good stuff snipped]
> Even though the open-owner seqid is no longer used, for appropriate
> processing, the server must serialize access to its data structures
> for state bearing operations.  Therefore, it is possible to have
> stateid4.seqid be transparent to the client and if the server were
> required to monotonically increase stateid4.seqid value at each OPEN,
> OPEN_DOWNGRADE, CLOSE, the client can benefit greatly.

I admit I'm not sure I understand what you mean by "transparent", but if
it implies that servers shouldn't use the seqid to determine whether or
not to return NFS4ERR_OLD_STATEID, that sounds fine to me.

I don't believe that a server returning NFS4ERR_OLD_STATEID when only the
seqid field of the stateid is "out-of-date" has proved useful to clients
and, as such, I think that should be deprecated.
Is this part of the proposal? rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 22 Aug 2006 14:18:16 -0500

> Is this part of the proposal? rick

I am proposing the opposite.  The server would use the stateid4.seqid to
"change" the stateid on each OPEN/OPEN(upgrade)/OPEN_DOWNGRADE/CLOSE.
The server would use the seqid (along with anything else it wants) to
see if the stateid is an OLD_STATEID and return that error to the client.

The client can use the stateid4.seqid to sort the responses it receives
from the server.  I am assuming in this model that the client submits
multiple OPEN, CLOSE requests under the same open-owner context and
will sort out the results.  In the general case, the client will not
have any overlap between the requests.  The overlap will come in the
form of multiple operations on the same file.  If the client is 
generating multiple requests for different files then everything 
flies through smoothly.

Spencer