[OpenAFS] Last Update not updating?
Tue, 10 Jan 2006 21:41:18 -0500
On Tuesday, January 10, 2006 09:31:09 AM +0100 Horst Birthelmer
> On Jan 10, 2006, at 3:18 AM, Jeffrey Hutzelman wrote:
>> On Monday, January 09, 2006 04:43:47 PM -0800 Mike Polek
>> <email@example.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.