From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 11/09/00-04:27:04 PM Z
Message-ID: <BC0FBE708897D4118C5500902745938E21E44A@black.eng.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: Delegation callback with stateid instead of filehandle(?) 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.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:24 AM Z CST