[OpenAFS-devel] Re: sanity check: client vldb cache time

[Andrew Deason]

On Wed, 22 Jan 2014 15:27:00 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> Additionally, every 12 times the 10-minute check runs (i.e. every 2
> hours), all mount points are invalidated, so that they must be
> reevaluated the next time they are traversed.  This means that except
> for RO volumes, name->id mappings are reevaluated at most once every 2
> hours.  Expiration of the volcache entry for an RW volume will cause
> us to check with the VLDB to see where that volume is located, but
> won't cause the mountpoint to be reparsed and the name->id mapping to
> be updated.

Okay, that makes sense as to where the 2 hours is coming from. But just
to be clear, I believe in the past it's been a problematic
oversimplification, since that figure has been used to describe evicting
VLDB entries in general. There are other things besides just the
name->id mapping, and many relevant questions have indeed involved
things like moving volumes around. I think that's even the most common
form of the VLDB cache time being relevant; sometimes
renamings/renumberings do happen, but that's rarer.

Also, just from looking at the code, I can't actually see where the
volcache entry is invalided for RW volumes. Both of the cases I
mentioned (afs_CheckCallbacks -> afs_ResetVolumeInfo, and
afs_CheckVolumeNames -> afs_ResetVolumeInfo), are only for RO volumes.
>From that, it seems possible that the RW information can be cached
forever, even if we can't contact the server; I'll have to experiment
with it, but that might explain some confusing behavior I had seen
reported before.

-- 
Andrew Deason
adeason@sinenomine.net