Subject: [nfsv4] Different interpretations of stateid.

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 21 Jun 2006 15:53:38 -0400

In some discussion that Mike Eisler and I had about some of
the pending issues in the v4.1 spec, I discovered that Mike
and I have very different interpretations of what a stateid
represents.  So Mike suggested that the working group discuss
this diveregnce of interpretation.

Mike wrote:
> Also, I've never though of a stateid necessarily being 1-1
> associated with a specific lock or a specifici file. Instead,
> it is a short hand for the lock or open owner.

I responded:
> Yet another case in which two people reading RFC3530 have entirely
> different readings of what is intended. My belief is that a stateid
> is associated with a particular file and designates all locks for
> a given owner on a given file. 

I also noted that the text of issue13 implies that stateid's are
associated with specific files:

pdmazz wrote:
> The working group had a discussion on what error to return when the
file handle
> does not match the given stateid. It was decided that the
NFS4ERR_BAD_STATEID
> was the better error code. See mail archives "what is a server to
do..." Jan 23,
> 2003.

So I'm wondering what various interpretations of stateid's people have?

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 21 Jun 2006 17:44:49 -0400

> associated with specific files:

I don't see any reason why a server couldn't return stateid's that are
bit-for-bit identical despite representing state on different files.

Every operation that takes a stateid also takes a filehandle, so the server
will always be able to determine the correct state to use from the (stateid,
filehandle) pair.

> pdmazz wrote:
> > The working group had a discussion on what error to return when the file
> > handle does not match the given stateid. It was decided that the
> > NFS4ERR_BAD_STATEID was the better error code.

I suppose there's no reason not to have a convention for an error to return in
that case, if you want to return an error.  But you'd need some argument to
show that servers must be required to generate stateid's that allow them to
distinguish this case.

On the face of it it doesn't seem like a very useful thing to require, since
the error isn't that useful to the client except as a debugging aid--I can't
see how this situation could arise between correctly functioning clients and
servers.

(The linux server actually does encode a fileid in the stateid, but only so it
can return BAD_STATEID in this one case.  So I don't see why we couldn't drop
the fileid later if we decided we needed that space in the stateid for
something else....)

--b.