[OpenAFS] Last Update not updating?

[Jeffrey Hutzelman]

On Tuesday, January 10, 2006 09:31:09 AM +0100 Horst Birthelmer 
<horst@riback.net> wrote:

>
> On Jan 10, 2006, at 3:18 AM, Jeffrey Hutzelman wrote:
>> On Monday, January 09, 2006 04:43:47 PM -0800 Mike Polek
>> <mike@pictage.com> wrote:
>
>>> 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.
>
> Jeff, I remember our talk at the 2004 Hackathon about this.
> The problem was not that the examine took too long.
> The problem was, that you could cause timeouts on file transfers, if  you
> do a few 'vos examine' calls, due to the disk operations those  calls
> would trigger.

Hrm.  Yeah, I'd forgotten about that.
But reporting out-of-date information is surprising and has turned out to 
break multiple sites' auto-release tools.


> BTW, 'vos release' won't do any transfer if the RW volumes didn't change.
incremental volume dump to each RO site.
Not true.  Unless there is a pending incomplete release, 'vos release' will 
always clone a new RO volume on the RW site, and will always do a 
VolForward from the newly-updated RO clone to each of the other replicas 
(after the first two, remaining replicas are updated in parallel).

Now, if nothing has actually changed, then the dump that is forwarded will 
be a fairly short incremental, containing only a list of the vnodes present 
in the volume.  But even so, it is necessary to lock the VLDB entry for the 
duration of the transaction, busy the RW volume long enough to clone it, 
and take each RO volume completely offline for the time it takes to apply 
the incremental dump -- which may be significant if there are many vnodes 
in the volume.  And to top it all off, attaching these volumes forces the 
volume data to be flushed, just as an examine would have under the old code.

Besides the performance impact on the servers, this means that "just 
release all the volumes in the cell" is considerably slower than examining 
each RW volume and its same-site RO volume and only releasing those which 
have changed, even when the examines are the slow kind.  People, including 
me, have auto-release tools because experience has shown that the 
just-release-everything approach is unacceptably slow.

-- Jeff