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.
Kim
Jeffrey Hutzelman wrote:
On Tuesday, January 10, 2006 09:31:09 AM +0100 Horst Birthelmer
<[EMAIL PROTECTED]> wrote:
On Jan 10, 2006, at 3:18 AM, Jeffrey Hutzelman wrote:
On Monday, January 09, 2006 04:43:47 PM -0800 Mike Polek
<[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
