[OpenAFS] 1.4.2fc3 client on RHEL5 beta 1

[Jeffrey Hutzelman]

On Friday, September 22, 2006 10:16:32 AM -0400 chas williams - CONTRACTOR 
<chas@cmf.nrl.navy.mil> wrote:

> In message <820DAED4B9415F2EEC8C73A6@sirius.fac.cs.cmu.edu>,Jeffrey
> Hutzelman w rites:
>> @@ -57,7 +57,7 @@
>> # include <afs/afs_sysnames.h>
>> # define AFS_USERSPACE_IP_ADDR 1
>> # define RXK_LISTENER_ENV 1
>> -#define AFS_GCPAGS       2	/* Set to Userdisabled, allow sysctl to
>> override */
>> +#define AFS_GCPAGS       0	/* Set to Userdisabled, allow sysctl to
>> override */
>
> just a comment on this with regard to keyring pag's.  the key's
> .destroy hook could be used to do away with the associated afs_user
> object immediately.  should this functionality always work (despite the
> AFS_GCPAGS setting)

I don't see why not.  As far as I'm concerned, GCPAGS is about whether or 
not we want to have a thread which explicitly looks for PAG's which are no 
longer referenced by any process and removing tokens and other cached data 
for those PAG's immediately.  Without it, we still do the cleanup, but not 
until the PAG has had no active tokens for a while.  What you're proposing 
would result in cleanup as soon as the PAG became unreferenced, without 
needing to actively scan processes.

Also, part of the point of making GCPAGS an option was so that it could be 
introduced without forcing people to use it.  The keyring code already has 
that property.


> and if so, should it just do the delete itself or
> flag the pag and let afs clean it up later?

Well, there are varying levels of agressiveness you could use.
You could do what GCPAGS does, which is set the token expiration time to 
zero and let the daemon thread take care of the rest.  Or, you could go all 
the way and nuke the tokens (like VIOCUNLOG does), and call 
afs_ResetAccessCache to nuke cached access rights and RemoveUserConns to 
nuke cached connections.  VIOCUNLOG just calls afs_ResetUserConns, which 
marks connections as reset but doesn't actually do the destroy, instead 
leaving that for later.  But VIOCUNLOG knows that the PAG still belongs to 
at least one process (the one calling unlog) and might get reused.

-- Jeff