Subject: RE: Delegation callback with stateid instead of filehandle(?)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 9 Nov 2000 14:27:04 -0800

> In my opinion, the delegation callbacks should be use stateids (delegation
> stateids, that is, which have a different meaning from "ordinary" stateids
> - -- see sec. 9.2 of the spec) to refer to delegations, rather than
> filehandles, for two reasons:

> 1.  A stateid is a lightweight 64-bit quantity, whereas a filehandle is a
> "heavyweight" opaque (max. length 128 bytes) object, so using the stateid
> instead of the filehandle will reduce bandwidth.

Not by a whole lot.  At least one file handle is sent to the server for
every operation the client performs.  In any expected use of callbacks,
the frequency is going to be considerably less than that of requests to
the server.  I think this pretty minor.  

> In fact, my
> understanding is that this is the whole purpose of the delegation stateid;
> the server issues the delegation stateid when it grants the delegation so
> that it can use the lightweight stateid to refer uniquely to the
> delegation in the future. It's similar to the SETCLIENTID operation, in
> which the server issues a clientid so that the client can refer to itself
> uniquely using the lightweight clientid rather than a heavyweight opaque
> identifying string.  The way the protocol is written now, a delegation
> stateid is issued by the server when a delegation is granted, and
> subsequently not used to refer to the delegation when callbacks are done.  
> Why bother issuing a stateid in the first place, if this is the case?  It
> seems to me that this is an unintended "oops" in the spec.

The other use of the delegation stateid is in requests that the client
makes to flush state to the server when the delgation is recalled.
The delegation stateid represents the basis on which the operation
is performed.  An example is an OPEN which is used to informa the server
that we do have a file open.  The delegation stateid represents our
right to do this, without conflict from anywone else.  If we didn't
present it, the server would recall the delegation, since the OPEN
conflicted.

> 2.  If the server uses volatile filehandles (e.g., our Linux server's
> filehandles are volatile on rename), both client and server have to keep
> additional state: the client has to store the filehandle _at the time the
> delegation was granted_ (in case the server later uses that filehandle to
> refer to the delegation in a callback), and the server has to store the
> filehandle at the time the delegation was granted (in case it needs to
> replay it to the client in a callback).

I can see this is a problem.

> My suggestion is that the .x file be modified by:
> 
> - - removing the 'fh' field from the definiton of 'struct CB_GETATTR4args',
> replacing it with a 'stateid' field
> - - removing the 'fh' field from the definition of 'struct CB_RECALL4args'
> (for some reason, CB_RECALL4args currently contains _both_ a filehandle
> and a stateid, so no new stateid field needs to be added, as in
> CB_GETATTR4args)

I would add the stateid to CB_GETATTR.  I see that makes the filehandle
redundant, but since I don't see that this would be a bandwidth problem
I'd prefer to keep the fh for checking given that we are entering rather
unexplored territory here.  Have something to error check is at least
good for peace of mind.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 13 Nov 2000 14:38:30 -0600

> the server.  I think this pretty minor.  

I agree.

<snip>

> I can see this is a problem.

It seems to me that if the server is going to expire a volatile
filehandle that it should recall the delegation.  I know that this is
not in the specification as it is now but it seems like a reasonable
thing to do to ease implementation in general (regardless of whether
we decide to add the stateid to the callback).  In the case of
expiration on rename, I think we had already decided to
suggest/require that the server recall a delegation on rename of an
OPEN file.

<snip>

-- 

- Spencer -