[OpenAFS-devel] Remediating Stale Host Info: Revving Afsint: Was: extended callbacks RPC modification

[Matt Benjamin]

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