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

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 24 Jun 2006 17:12:04 -0400

I wrote:
> I also note that if the relationship between stateid and owner were 
> intended to be a simple one-to-one relationship, the spec would be 
> expected to say so.

Duh.  RTFRFC.  Section 8.1.3 of RFC3530 says:

   When the server grants the lock, it responds with a unique stateid.
   The stateid is used as a shorthand reference to the lock_owner, since
   the server will be maintaining the correspondence between them.

One point for Mike's position.

But also, it says:

   The server must be able to distinguish the following situations and
   return the error as specified:

   o  The stateid was generated by an earlier server instance (i.e.,
      before a server reboot).  The error NFS4ERR_STALE_STATEID should
      be returned.

   o  The stateid was generated by the current server instance but the
      stateid no longer designates the current locking state for the
      lockowner-file pair in question (i.e., one or more locking
      operations has occurred).  The error NFS4ERR_OLD_STATEID should be
      returned.

      This error condition will only occur when the client issues a
      locking request which changes a stateid while an I/O request that
      uses that stateid is outstanding.

   o  The stateid was generated by the current server instance but the
      stateid does not designate a locking state for any active
      lockowner-file pair.  The error NFS4ERR_BAD_STATEID should be
      returned.

And that seems to indicate pretty clearly that a statid represents more
than just a lockowner, but a lockowner-file pair.

One point to the other side. 

But also note that Rick seems to have proved that at least in the case
of a lock stateid, it cannot represent simply a lockowner but must 
encode, in addition, information about the openowner, whether in also
encodes the ifle in addition or note.

Further, we have delegation stateids, which, since delegations are not
associated with a specific owner, but with the client as a whole, do not
encode a lockowner or a lockowner-file pair.

So we have two different explanations of stateid in the spec, they 
contradict each other, and further they are contradicted in turn by
various pieces of the details of the protocol defined by the spec.
We seem to have a bit of a mess.

On the other hand, if you just use the stateid provided by open, lock,
etc., in the obvious ways suggested by the operation definitions and 
ignore the explanatory text it seems that we have a protocol
that works despite the fact that different people have different 
interpretations of what a stateid really is (and all of those
interpretations, at least ones written down are in some respect 
wrong).

I'm going to open an issue in the issue tracker to come up with 
explanatory text that matches the protocol as implemented by
current interoperable clients and servers. 

-----Original Message-----
From: Noveck, Dave 
Sent: Friday, June 23, 2006 5:35 PM
To: Benny Halevy; [email-masked]
Cc: [email-masked]
Subject: RE: [nfsv4] Different interpretations of stateid.

> My interpretation was always that the stateid is associated with the
file.

So's mine, but more to the point so is Rick's.  You appear to be in
violent agreement.

> I think you took "not useful for operations that follow" in 14.2.2 out
of 
> context.  Here's the full context:

Clearly you can always give more context but "out of context" suggests
that Rick somehow shortchanged us by not giving more context.  I don't
have that impression.

> My quote would then be "CLOSE "shuts down" the state associated with
all OPENs 
> for the file by a single open_owner".  Hence the stateid represents
"the state
> associated with all OPENs for the file by a single open_owner" and
"operations
> that follow" relate to state changing operations issued by this
open_owner
> on this file.

To me "not useful for operations that follow" means that there are no
operations for which it useful.  Clearly, for every stateid, there are
some operations for which it is not useful.

I conclude that Rick is right and that this statement does at least
suggest that stateids are associated with files and are not simply a
shorthand for an owner.
I also note that if the relationship between stateid and owner were
intended to be a simple one-to-one relationship, the spec would be
expected to say so.  You can't make a conclusive case from the absence
of something, but it does add weight to the view that the each stateid
is limited to a file and is not just a shorthand for an owner.

Also I think Rick's second point is important.  Even if a stateid is not
tied to a file, a lock stateid cannot just be a shorthand for a
lockowner but has to include some notion of the openowner, so that it
would at least have to encode an openowner/lockowner pair even if it
didn't include an indication of the file.

Rather than engage in a detailed picking apart of the spec for the "true
meaning"
of stateid however, I think we should focus on making sure that existing
clients and servers can be upgraded to v4.1.  We do not want to make a
choice here that will invalidate the basic data structure handling of
any client or server no matter how arguably correct that would be based
on an analysis of the intent of RFC3530.  After all, the authors of
RFC3530 disagree on what stateid means (which does suggest a problem in
our review process that I'd like not to repeat).

So given that many servers exist which give out different stateids for
different files, even with the same owner, it seems clear that no client
can be written depending on an assumption that the stateid is a
shorthand for an owner, That is, it cannot be surprised or object to
getting two different stateids for the same openowner (which it might if
it were a shorthand for an openowner) and it can't use one stateid
instead of another it got when opening a different file (which would be
valid if a stateid were a shorthand for an openowner, but will not work
on such servers).

So it seems clients, even their authors believe that the stateid is a
shorthand for an owner, must act as if it is tied to a file, or at least
they must be extraordinarily tolerant of servers that act as if a
stateid is tied to a file.

So this leaves a question about servers.  Are there servers out there
that act on the assumption that a stateid does not include an indication
of the file and that an open stateid is a shorthand for a openowner, and
that a lock stateid is a shorthand for lockowner/openowner pair (I don't
think it would work for it to be a shorthand for a lockowner)?  I think
whether any such servers exists is very important in deciding how we
address this going forward.

If such servers exist then I think we have to define the clients view so
that it accommodates either approach.  We still might want to do this
even if such servers don't exist, but we don't have to.

One way that might resolve this is the following:

     At a conceptual level, a stateid designates a file/openowner pair
(for an
     open stateid) or a file/openowner/lockowner triple.

     The stateid assignment spaces from the client viewpoint are to be
treated
     as segmented by filehandle, so that any comparison of the bit
patterns of
     stateids associated with different filehandles or a transfer of one
to the
     other is prohibited.

     A server may choose to assign the same bit pattern to stateids
associated
     with different filehandles so that the same owner is associated
with the
     same bit pattern on different files but if it does not it must not
allow
     a filehandle to be used with an inappropriate stateid.  For
example, if 
     I open A with owner Q and get stateid X.  I may not use that
stateid with
     file B if owner Q never opened file B.  That needs to get a
BAD_STATEID
     error.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]]
Sent: Thursday, June 22, 2006 2:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] Different interpretations of stateid.

[email-masked] wrote:
> In case my post yesterday wasn't clear (I'm usually not:-), here's an
> example assuming that an open_owner isn't tied to a file:
> - client opens foo with owner "xxx", gets stateidXXX
> - client opens bar with owner "xxx", gets stateidXXX
> - client closes foo with stateidXXX
> *** stateidXXX is "not useful for operations that follow"
> - client closes bar with stateidXXX
> --> server fails this with something like NFS4ERR_BADSTATEID, since
stateidXXX
>     was rendered "not useful for operations that follow" by the
previous close
> 
> Of course "not useful for operations that follow" is quoted from the
end of
> the IMPLEMENTATION para of sec. 14.2.2.
> 
> Whereas, if the server issues distinct stateids for each open:
> - client opens foo with owner "xxx", gets stateidXXXfoo
> - client opens bar with owner "xxx", gets stateidXXXbar
> - client closes foo with stateidXXXfoo
> - client closes bar with stateidXXXbar
> 
> The only way I can see the first example working is if "not useful for
> operations that follow" doesn't mean what I read it to mean? rick

My interpretation was always that the stateid is associated with the
file.
I think you took "not useful for operations that follow" in 14.2.2 out
of 
context.  Here's the full context:

    Even though CLOSE returns a stateid, this stateid is not useful to
    the client and should be treated as deprecated.  CLOSE "shuts down"
    the state associated with all OPENs for the file by a single
    open_owner.  As noted above, CLOSE will either release all file
    locking state or return an error.  Therefore, the stateid returned
by
    CLOSE is not useful for operations that follow.

My quote would then be "CLOSE "shuts down" the state associated with all
OPENs 
for the file by a single open_owner".  Hence the stateid represents "the
state
associated with all OPENs for the file by a single open_owner" and
"operations
that follow" relate to state changing operations issued by this
open_owner
on this file.

> 
> _______________________________________________
> 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

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 24 Jun 2006 18:38:44 -0400

> We seem to have a bit of a mess.

I'm a little lost--has anyone identified an actual problem here?  I don't think
I've yet seen anyone given an example where a client and a server would fail to
interoperate because their implementors took two different "interpretations" of
the stateid.

> interpretations of what a stateid really is

And, in fact, it's not the job of the protocol specification to say what
different objects "mean".  Its job is to describe how compliant implementations
use them.

If we can assign them a simple consistent "meaning", that may be an aid in
understanding or implementing the spec.  But the essential thing is to make
sure that the description of how they are to be used is complete and correct.

--b.