[OpenAFS] Last Update not updating?
Thu, 19 Jan 2006 07:32:39 -0700
UAL also has such an auto-release tool. Before I left there we'd queue
several thousand release requests from an automated system; vos exa
update compares would usually reduce these to < 100, in many cases to <
10, and sometimes to 0.
Prior to implementing the update-time comparisons our nightly vos rel
queue often took > 24 hours to process. Post implementation queue
processing was at most on the order of several hours.
I don't know if they plan to move to OpenAFS or if they already have,
but will give Ted a heads up in any case.
Jeffrey Hutzelman wrote:
> On Tuesday, January 10, 2006 09:31:09 AM +0100 Horst Birthelmer
> <email@example.com> wrote:
>> On Jan 10, 2006, at 3:18 AM, Jeffrey Hutzelman wrote:
>>> On Monday, January 09, 2006 04:43:47 PM -0800 Mike Polek
>>> <firstname.lastname@example.org> 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
>> 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
> 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
> 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
> OpenAFS-info mailing list