Subject: [nfsv4] Current stateid proposal

From: David Robinson <[email-masked]>
Date: Fri, 15 Jul 2005 18:07:04 -0500

This late I-D some how slipped through and got posted
after the cutoff. I don't expect it to be discussed in
Paris (and I won't be there anyways).

So for your amusement:

http://www.ietf.org/internet-drafts/draft-robinson-curstateid-00.txt

Abstract

    The semantics of the NFSv4 server are changed to include tracking the
    value of current stateid in addition to the existing current
    filehandle.  This will allow the stateid generated by one operation
    to be used by a subsequent operation without incurring an additional
    round trip.

	-David

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

---

From: eric kustarz <[email-masked]>
Date: Fri, 15 Jul 2005 17:44:36 -0700

>    to be used by a subsequent operation without incurring an additional

So in general, do we use the "hierarchy" of stateids (delegation > lock 
 > open > special)?

Then, OPEN would set the current stateid to the delegation stateid if it 
returns a delegation; otherwise it sets the current stateid to the open 
stateid?

And LOCK always sets the current stateid to the lock stateid (even if 
this was a first time lock request that included the open stateid)?

eric

---

From: David Robinson <[email-masked]>
Date: Sun, 17 Jul 2005 20:35:33 -0500

On Jul 15, 2005, at 7:44 PM, eric kustarz wrote:
> So in general, do we use the "hierarchy" of stateids (delegation > 
> lock > open > special)?
>
> Then, OPEN would set the current stateid to the delegation stateid if 
> it returns a delegation; otherwise it sets the current stateid to the 
> open stateid?
>

Ah ha, you have pointed out an ambiguity.  My intent is that the
current stateid should be set to the stateid that was generated
in the last operation,  so the current stateid after a LOCK will
always be LOCK4res.LOCK4resok.lock_stateid.

But in a OPEN4res there is more than one stateid, which one is
the current stateid? By argument of most usefulness within the
same request, there is little that can be done with a delgation
stateid so the current stateid should be set to the
OPEN4res.OPEN4resok.stateid.

But there really isn't an ambiguity as the next operation that has
as an argument an all-zero stateid will make it obvious what is
needed. If the OPEN is followed by a LOCK the open stateid
should be used, if followed by a DELEGRETURN (hmmm
interesting idea) it would be the delegation stateid. But since
there is no guarentee that you will get a delegation, trying
to use the delegation stateid in the same COMPOUND is
a dubious construct at best.

	-David

---

From: Benny Halevy <[email-masked]>
Date: Tue, 19 Jul 2005 17:26:34 +0300

David,

in section 2 you write:
	Those operations that do not return a stateid MUST
	set the current stateid to the special all-zeros
	stateid.

I think that this should be restricted to operations that 
change the current filehandle.  If I send a <open, getattr, 
lock, read> compound, I wouldn't want the getattr operation 
to discard the stateid returned by open.

Benny

---

From: David Robinson <[email-masked]>
Date: Tue, 19 Jul 2005 10:50:38 -0500

Benny Halevy wrote:
> I think that this should be restricted to operations that change the 
> current filehandle.  If I send a <open, getattr, lock, read> compound, I 
> wouldn't want the getattr operation to discard the stateid returned by 
> open.

Bad english, this is just a dangling reference in that paragraph
which calls out in the first sentence exactly your point.  The second
and third sentences were intended to just enumerate the two cases
of the first sentence:

    Any NFSv4 operation that modifies the current filehandle MUST also
    modify the current stateid.  Those operations that also return a
    stateid MUST set the current stateid to that value.  Those operations
    that do not return a stateid MUST set the current stateid to the
    special all-zeros stateid.

I'll clean up the language.

	-David

---

From: eric kustarz <[email-masked]>
Date: Tue, 19 Jul 2005 09:56:28 -0700

David Robinson wrote:
>> current filehandle.  If I send a <open, getattr, lock, read> compound, 
>> I wouldn't want the getattr operation to discard the stateid returned 
>> by open.
> 
> 

Maybe i'm missing something... so for the example compound: {open, 
getattr, lock, read}

1) open sets the current fh and returns a stateid, so current stateid is 
set to newly created open stateid

2) getattr does not set the current fh nor return a stateid, so it sets 
the current stateid to all-zeros.

3) lock was presumably sent with a all-zeros stateid in its args, that 
is detected and its switched with the current stateid (which is also 
all-zeros).  I don't think thats what we want...

A GETFH after the OPEN would cause the same problem.  Is there any 
reason why a non-current fh changing and non-stateid returning op has to 
clear out the current stateid?

eric

---

From: David Robinson <[email-masked]>
Date: Tue, 19 Jul 2005 12:24:31 -0500

> Maybe i'm missing something... so for the example compound: {open, 

Let's make it a bit more realistic:
	{putfh, open, getattr, lock, read}

0) putfh set the current fh to be the directory filehandle and the
    current stateid is 0's:  {dfh, 0..0}

> set to newly created open stateid

Correct, it will now have {fh1, sid1}

> the current stateid to all-zeros.

No, the intent is that if the operation does not change the current
fh and does not return a stateid, it MUST NOT change the current
stateid.  This is symetrical with current fh semantics. So we will
still have {fh1, sid1}

> all-zeros).  I don't think thats what we want...

If the lock was sent with an all zero's stateid, it will use the
current file handle and stateid set by the open: {fh1, sid1} and
because it changes the stateid it will leave {fh1, sid2}

> clear out the current stateid?

Since GETFH does not change the current filehandle or return a stateid
it will not change either.

Again, bad english on my part. The paragraph was only supposed to
be addressing the case where the operation changes the current
filehandle.

To put it in engineering terms:

	Sets CFH?	Returns stateid?   =>	{CFH,  CSID}
	No		No			{same, same}
	No		Yes			{same, new}
	Yes		No			{new,  0's}
	Yes		Yes			{new,  new}

In trying to describe the interesting third case I seem to have confused
the other straight forward cases. Sigh...

	-David