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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 21 Jun 2006 20:41:02 -0400

That's the interpretation I always had and when Mike
told me his I was very surprised but I can't say that it 
is wrong, at least I don't see where the spec makes
it wrong.

Is there some reason we need pick one interpretation
over the other for v4.1 or should we maintain the status
quo that allows both?

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, June 21, 2006 8:36 PM
To: [email-masked]
Subject: Re: [nfsv4] Different interpretations of stateid.

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.

On Wed, Noveck, Dave wrote:
> 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

_______________________________________________
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: Wed, 21 Jun 2006 20:04:16 -0500

> is wrong, at least I don't see where the spec makes

Certainly, my world view is more specific and not required
when mandatory file locking is NOT being provided.

The protocol needs to provide a mechanism that allows
the client to model its operating environment in such
a way that the server can arbitrate access.

The example I have for this is a Posix client that is 
dealing with file locking semantics.  So the client needs
to differentiate the processes doing file locking such
that the server can arbitrate those locks.  So at a minimum,
the lock_owner needs to signify a process
in the posix world.  

We chose the file_handle/lock_owner/stateid association
to allow for this and the desired parellelism for multiple
applications all doing file locking on separate files.
As we know, the lock_owner/stateid association was made
in support of mandatory file locking but also the sequencing
requirements.

So, the server doesn't need to change the lock_stateid
once established by the first LOCK.  It does need to
differentiate between file_handle/lock_stateid pairs
when making file locking decisions.

This does mean that file locking is not associated directly
with the open_owner in that it is not the 
file_handle/open_owner/open_stateid that represents file locking.

The file_handle/open_owner/open_stateid does represent
the share state and as we know it is similar to file locking
so has similar behavior and requirements to support the
client operating environment and performance characteristics.

> over the other for v4.1 or should we maintain the status

My personal choice would be my current interpretation because
it does offer barriers to READ/WRITE when the file locking
state changes.  Is that a requirement outside of mandatory
file locking, no.  Just my preference.

Will the simpler interpretation work, sure.

Do we need to make a choice?  No.

Should it be clear what is intended or allowed.  Definitely. :-)

Spencer