[OpenAFS] 1.4.2fc3 client on RHEL5 beta 1

Jeffrey Hutzelman jhutz@cmu.edu
Fri, 22 Sep 2006 16:01:17 -0400


On Friday, September 22, 2006 03:10:29 PM -0400 chas williams - CONTRACTOR 
<chas@cmf.nrl.navy.mil> wrote:

> In message <422BECEAEDD061ADEEAFDFF8@sirius.fac.cs.cmu.edu>,Jeffrey
> Hutzelman w rites:
>> 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.
>
> i submitted a patch, bug #40659.
>
> i took the path of least resistance and set the TMP_UPAGNotReferenced.
> its easy and gets the right behavior is gc is on without needing to
> scan the entire process table.  i cant recall if afs needs to hold
> on to the credentials after the process has exited (async writes?).
> skipping a step and expiring the token seems fine though.
>
> this doesnt solve the problem of scanning the process table for uid
> based tokens.  my aim was to eliminate part of the next for locking
> the tasklist.

It solves the problem that GCPAGS was intended to solve, which is systems 
where non-uid PAGs are created so frequently that you start having problems 
if you wait to remove their tokens until they expire.

I don't think uid-based PAG's are a big deal, at least for the moment.