[OpenAFS] Last Update not updating?

[Jeffrey Hutzelman]

On Monday, January 09, 2006 04:43:47 PM -0800 Mike Polek <mike@pictage.com> 
wrote:

>> As a result of this change, the 'last update' date reported by 'vos
>> examine' can sometimes be incorrect, if the volume has been modified
>> since the last time the fileserver wrote the volume header to disk.  The
>> maximum amount of time that can pass between the time a change is made
>> and the time it is reflected in the volume header is about 25 minutes;
>
> Is this tunable?

No; it's not even a single timeout.  There are a variety of interrelated 
mechanisms involved, and the actual time can vary quite a bit depending on 
what sorts of updates are happening, how many, and the exact phase 
difference between several recurring operations that happen at different 
rates.  The number I gave is an upper bound; the longest it could ever take.



>> this number is smaller for some kinds of changes, or if the number of
>> changes is very large.  Operations for which it is crucial to have the
>> latest volume header data, such as volume dumps, moves, and releases,
>> will continue to use the correct data, as before.
>
> Good to know. The reason I'm looking at it is that I have a perl
> script that will release a set of volumes, but only if they
> need it. It checks the updateDate of the volume and compares
> it to the updateDate of the cloneID if there is one to
> figure out if the volume needs to be released.

Yup; we have that too.  It doesn't notice changes made too close before it 
runs.  That's one of the reasons I'm looking at making 'vos examine' go 
back to the slower, more accurate results.


> I guess I should
> scrap it and just call vos->release(<vol>)? It seemed to be
> the case that doing that was generally slower than just
> checking timestamps.

It is.


> Is there another alternative that I haven't considered?

Not really.


-- Jeff