Subject: [nfsv4] server use of stateid after CLOSE

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 8 Sep 2011 18:33:50 -0400

On close I believe a server could do two different things with the
stateid:

	- retire the "other" field of the stateid, and never use it
	  again.  If another open is done for this (file, owner), it
	  will get a new stateid with a new "other" field.
	- continue to use the "other" field of the stateid, incrementing
	  the seqid field on the next open.

It looks to me like either is legal server behavior; does anyone
disagree?

The language of 8.2.2:

	When such a set of locks is first created the server returns a
	stateid with seqid value of one.

means the client *can* tell the difference between the two cases.  And
you might be able to concoct a theoretical client implementation that
used some assumption about the seqid in such a case.

I'm curious, though, if I'm correct, and either of the behaviors above
is OK, why we bother to require an initial seqid of one, since the
client then often can't know when it's dealing with a truly "new"
stateid or not.

(Also, a nit to fix if there's ever a 5661bis: section 3.3.12 says that
the initial value of the seqid is undefined, which contradicts the
excerpt from 8.2.2 above.)

--b.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 8 Sep 2011 17:44:41 -0500

> excerpt from 8.2.2 above.)

One of the takeaways from the 3530bis work was that it is very important
to make edits when you find problems and not wait for years to pass. So,
even though 5661bis is not part of our charter, I have been applying 5661
errata to this git repository:

[email-masked]:loghyr/5661bis.git

The goal is that if we incorporate 5661bis into our charter, the editor(s)
of such a document can build on this work.

Short form, I'm willing to take your modifications to section 3.3.12.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 8 Sep 2011 22:50:44 +0000

5661 errata should be posted through the errata process such that
they can be vetted and accepted such that other readers of 5661 will
be able to find them readily.  My preference is that errata-like issues
be passed by the working group first to ensure that we have the best
chance of the "right" content being submitted to the errata system but
this is not necessary - anyone can submit errata here:
http://www.rfc-editor.org/errata.php

You can also generate errata reports with the above page as well.

Keeping a pre-5661bis git repository is prudent but not sufficient.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Haynes
> Sent: Thursday, September 08, 2011 3:45 PM
> To: J. Bruce Fields
> Cc: [email-masked]
> Subject: Re: [nfsv4] server use of stateid after CLOSE
> 
> 
> > (Also, a nit to fix if there's ever a 5661bis: section 3.3.12 says
> > that the initial value of the seqid is undefined, which contradicts
> > the excerpt from 8.2.2 above.)
> >
> > --b.
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Rick Macklem <[email-masked]>
Date: Thu, 8 Sep 2011 21:12:09 -0400 (EDT)

> stateid with seqid value of one.
I think you could argue that a close followed by an open of the same
file/lockowner doesn't constitute "first created"?

> client then often can't know when it's dealing with a truly "new"
I agree that the concept of "new" (or "first created" as it's called above)
isn't clear and, as such, I think a client should simply consider a
stateid (seqid + other) an opaque blob of bits.

This also implies I agree that specifying an initial value for "seqid"
doesn't make much sense.

There might be an argument that a client could "time order" changes to
lock state using the "seqid" field of the stateid. I don't know if any
client would do this, but it still doesn't require a specific initial
value, just that it be incremented each time the lock state changes.

> that