[OpenAFS] Last Update not updating?

[Kim Kimball]

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 
> <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
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info