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

From: Spencer Shepler <[email-masked]>
Date: Tue, 7 Nov 2000 02:33:50 -0600

> 
> 6) Server references delegations by FH, not stateid
> 
> The one person who implemented delegations (Kendrick), found that it
> was inconvenient that the delegation recall was in terms of a
> filehandle and the delegation stateid is a more convenient
> alternative.
> 
> Since this only affects callbacks, making this change would not
> seriously affect existing implications. The consensus is that it makes
> sense to do this.

Can Kendrick provide additional details of why a delegation stateid is
more convenient?  Why is filehandle difficult to deal with on the
callback.

Spencer

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 09 Nov 2000 12:36:48 -0500

i'm sending kendricks response - kendrick is off line for a bit..

-->Andy

--------------  Forwarded Message ------------

> more convenient?  Why is filehandle difficult to deal with on the

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

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).

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)

Kendrick

------- End of Forwarded Message

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 14 Nov 2000 12:25:45 -0800

> > 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).

I think requiring the server to do this is reasonable.    

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

The spec already says so, but it needs a little bit of work in
dealing with the case of rename of the enclosing directories.