Subject: RE: [nfsv4] Different interpretations of stateid.

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 21 Jun 2006 19:29:39 -0400

So here is my summary.  Please tell me if anybody sees
something they think is wrong:

People indeed think about this in different ways so that
RFC3530 is kind of ambiguous.

This ambiguity has not caused any problems in practice.

The combination of a stateid together with current file
handle designates the set of locks held by a particular
owner on a particular file.

A server may implement the above by making a stateid a
shorthand for an openowner or a lockowner and using the
current filehandle together with the stateid to determine
the set of locks being designated.

A server may also implement the above be making a stateid
designate all the locks held by a given openowner or 
loockowner on a particular file.  If it does this, it
must return BAD_STATEID when the current file handle
designates a different file from the one associated with 
the stateid.

One reason that the server might choose the latter approach
is to reduce false conflicts due to change in the stateid
sequence resulting in extra OLD_STATEID errors.

Any other issues that might affect this choice?

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]]
Sent: Wednesday, June 21, 2006 5:45 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Different interpretations of stateid.

On Wed, Jun 21, 2006 at 03:53:38PM -0400, Noveck, Dave wrote:
> 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:

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.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 21 Jun 2006 19:40:02 -0400

> sequence resulting in extra OLD_STATEID errors.

Probably just me being slow, but I'm not following you here.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 21 Jun 2006 19:36:17 -0500

I have always had the interpretation that the lock_stateid
is associated with file/open_stateid/lock_owner because
of the association made in the over the wire protocol.
I have always presented it this way in IETF discussions
and elsewhere.

I have also interpreted the spec such that on each lock/unlock
of the file that the lock_stateid would change such that
the server could determine if read/write requests match
the client's view of the file locking state at the server (and
the same goes for the open/open_upgrade sequence).  This
is only required if the server implements mandatory file locking
but I thought it was a good idea since it was one thing
that the NFSv4 protocol allowed.