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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 22 Aug 2006 15:37:09 -0400

Spencer wrote:
> > 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.

What are you proposing with regard to LOCK, LOCKU?  Also what about
OLD_STATEID and ops other than CLOSE and OPEN_DOWNGRADE?

Rick wrote:
> 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 agree with you about OLD_STATEID for v4.0 but I think parallel
opens, enabled by sessions in v4.1, means that this does have an 
important use, at least for CLOSE and OPEN_DOWNGRADE.

I agree though that this doesn't really provide any value in the case
of LOCK, LOCKU, READ, WRITE, SETATTR, etc.  In those cases, the server
can use the code part of the stateid to get what it thinks is the 
current status of that stateid and act accordingly.  Rather than 
depreate OLD_STATEID, I would simply remove that as a valid error
for all the ops other than CLOSE and OPEN_DOWNGRADE.

As Trond has pointed out, for these ops, returning OLD_STATEID allows
you to do parallel opens and closes even the presence of hard links,
without any worries about things being done in the wrong order. 

Spencer wrote:
> The client can use the stateid4.seqid to sort the responses it
receives
> from the server.

I have no problem with the client doing this if it is a "may", but I
can't see the value for the client.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, August 22, 2006 3:18 PM
To: [email-masked]
Subject: Re: [nfsv4] proposal to make stateid4.seqid transparent

On Tue, [email-masked] wrote:
> [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

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

_______________________________________________
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: Spencer Shepler <[email-masked]>
Date: Tue, 22 Aug 2006 18:14:15 -0500

> can't see the value for the client.

The client can choose to serialize its operations on the open-owner
or not.  If it chooses the parallel model then it has to deal
with the results of ordering issues.  So, yes, "may" is the best
description.

The upgrade scenario is the only one that comes to mind for which
the client would need to sort out the stateid usage such that it
can downgrade in the appropriate order (if necessary).

> OLD_STATEID and ops other than CLOSE and OPEN_DOWNGRADE?

So, the first OPEN for an open-owner/file pair would
return stateid4.seqid == 0.  For subsequent OPEN (upgrades)
the stateid4.seqid would be +1.  The same would be true
for OPEN_DOWNGRADE and CLOSE.

After a CLOSE of a file and subsequent OPEN, if the server chooses
the same stateid4.other value, it must continue to increment the
stateid4.seqid from where it left off.  If another value for stateid4.other
is chosen, then the stateid4.seqid == 0.

Since the byte range file locking is inherently serial in nature,
the isn't a requirement to have the lock-stateid stateid4.seqid
to be monotonically increasing since the clinet is unlikely to
submit parallel requests.

> for all the ops other than CLOSE and OPEN_DOWNGRADE.

Given the recent clarifications in interpretation, this implies
that the server will return one stateid as a result of LOCK and LOCKU
for the duration of the associated open-owner?  

This also means that when a READ, WRITE, SETATTR is done with a
stateid4 that represents a CLOSEd file that the error returned
will be BAD_STATEID.

We have therefore removed the expectation that for advisory file
locks that there is a membar provided by the change of stateid
on LOCK and LOCKU and subsequent use by READ, WRITE, SETATTR.

Spencer