Subject: Size of stateid's

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 27 Oct 1999 07:36:03 -0700

In our discussion at the bake-off, I think we were
leaning to the view that 64 bits was not big enough
for a stateid, or at least that it seems kind of
tight.

Do you still feel this way?  If we are going to 
change this, I'd like to make this change before
everybody starts implementing this stuff, and 
into the next go-round of the spec.

I think we were assuming that going from 64 to
128 was the logical move, but I'm not sure powers
of two help here, so I'd be happy with 96 bits,
as opaque[12].

---

From: Neil Brown <[email-masked]>
Date: Thu, 28 Oct 1999 16:05:16 +1000 (EST)

> for a stateid, or at least that it seems kind of
( This reply is also in response to the earlier article by Dave about
stateids).

Is it just my imagination, or are stateids starting to look a lot like
file handles?

1/ Stateids are allocated by the server and used by the client, just
   like file handles.
2/ Stateids need to be bigish, and probably contain a structure that
   is opaque to the client, just like filehandles. 
3/ Stateids must accompany every IO request, just like file handles.
4/ Stateids might get DEADSTATE (STALE?) or BADSTATE (FHEXPIRED?)
   responses, much like file handles.
5/ A stateid uniquely identifies a file (plus some other info) just
   like a filehandle.

Obviously there are differences too, I think that everywhere a
filehandle is used, as stateid would contain enough information to be
used instead.

So the conclusion that this observation seems to bring me to is:

 There are two types of "filehandles" (though actually is another
 dimension to the typing of filehandles. We already have some sort of
 persistant/volatile distinciton).  We will call them "open" and 
 "non-open" file handles.

 LOOKUP (and LOOKUPP and PUTROOTFH) will return a "non-open" file handle.

 All "state changing" requests (OPEN, LOCK, LOCKU, CLOSE, DELEGRETURN)
 don't return a stateid, but instead set the current filehandle.  The
 "input" file handle must be "open" except for OPEN. The "output"
 filehandle will be "open" except for "close". This output filehandle
 is understood to refer to the same file as the "input" filehandle,
 but with extra (or less) locking state. 
 (CLOSE doesn't really need an output file handle, but is pleasingly
 symetric is it provides one)

 read/write requests no longer need a stateid.  The relevant locking
 state is already encoded in the filehandle.
 This would also serve to allow a 
    open/lock/read
 sequence in one compound op, which previously was not possible because
 there was no way to get the stateid from the open into the lock and
 then into the read.
 A read/write request on a "non-open" filehandle would be treated like
 a read/write with an all-zeros stateid (or maybe an all-ones
 stateid).

 You would probably still need that same range of error responses
 (STATE, FHEXPIRED, GRACE, DEADSTATE, BADSTATE, OLDSTATE, EXPIRED,
 NOLOCK) to indicate in what way the filehandle was not accepted.
 It might be nice for some of these to be returned by "PUTFH" rather
 than the actual operation.

An obvious implementation would be for the server to simply catenate
the non-open filehandle and the stateid, and for the client to treat
the "open" filehandle much like it currently treats the "stateid",
except when actually building an RPC request.

Given this, you don't have to decide in advance how big a stateid
should be.  The server chooses a size.

You might want the extend the maximum size of a filehandle some
more, but with the current max of 128 bytes, the client will
probably be dynamically allocating space anyway.

NeilBrown