-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Tom,
I think I get this generally, but I had the following thoughts (some that we discussed in IM): 1. would it make sense to use an RPC union to package the ClientAssertion (maybe with some other info you've also suggested we may wish to be sending to clients 'just FYI' to support heuristics for callback discard (which I also want to propose))? 2. Biting the bullet, is it appropriate that we perhaps re-open the discussion of revving afsint now? I think we collectively must know most of what's going to be in it? - From Felix we have a proposal for AFSFetchStatus64 which is probably close to ready for proposal to AFS3-Standardization. Your proposal to add client UUID to operations seems well motivated to me. Is there something else obvious? Access control information was mentioned by Derrick (though I don't know if anything is changing there). If we gave some thought to other widening of interfaces we certainly need--especially, if we could work out some future-proofing (unions again? perhaps this is being overused, but I'm not sure)--would we have something that could be proposed? Matt Tom Keiser wrote: > Matt, et al. > > <Developer/strategists>, Steven and I had a long conversation this morning > about > the host package. We were discussing potential ways to mitigate the > problems caused by using ephemeral, potentially stale (host,port) tuples > to map onto host objects. Until we can revise afsint to pass the cache > manager's uuid as an additional IN parameter to every stateful > fileserver RPC, I'd like to propose a stop-gap. Namely, that we pass a > cm uuid assertion as an additional IN parameter to > RXAFSCB_ExtendedCallBack: > > proc ExtendedCallBack( > IN HostIdentifier *Server, > > + IN afsUUID *ClientAssertion, > > IN AFSCBFids *Fids_Array, > > IN AFSExtendedCallBackSeq *CallBacks_Array, > > OUT AFSExtendedCallBackRSeq *CallBack_Result_Array > > } multi = 65540; > > > Furthermore, I propose addition of a new et code which notifies the > fileserver that the callback RPC failed due to a cm uuid mismatch. > > These additions will allow the fileserver to quickly detect staleness in > its struct Interface cache. I consider this to be a rather important > addtion, as the current implementation can lead to loss of cache > coherence when a (host,port) tuple drifts between hosts. > > If we can reach internal consensus, I'll volunteer to post a new xcb > draft to afs3-standardization. > > Thoughts? > > -Tom - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuq15JiSUUSaRdSURCBN4AJwMvB83eeSqzPadLryIT3r2rVZq0ACeN+ae C6e2S+2h0DdkA4UA7utNjkI= =aW5u -----END PGP SIGNATURE----- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
