[OpenAFS] Last Update not updating?
Mon, 09 Jan 2006 16:43:47 -0800
Jeffrey Hutzelman wrote:
> As it turns out, what matters here is not your clients, but your
> servers, which I assume are also 1.4.0.
That is accurate.
> This behavior is expected with
> newer servers, due to a performance improvement in the way the volserver
> handles the requests made by 'vos examine' and 'vos listvol'.
Thank you for the explanation. That makes sense.
> As a result of this change, the 'last update' date reported by 'vos
> examine' can sometimes be incorrect, if the volume has been modified
> since the last time the fileserver wrote the volume header to disk. The
> maximum amount of time that can pass between the time a change is made
> and the time it is reflected in the volume header is about 25 minutes;
Is this tunable?
> this number is smaller for some kinds of changes, or if the number of
> changes is very large. Operations for which it is crucial to have the
> latest volume header data, such as volume dumps, moves, and releases,
> will continue to use the correct data, as before.
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. I guess I should
scrap it and just call vos->release(<vol>)? It seemed to be
the case that doing that was generally slower than just
checking timestamps. Is there another alternative that I
> I have a change in mind which will cause 'vos examine' to report more
> accurate data while still retaining the performance gains for 'vos
> listvol'. However, I do not expect this to be done in time for 1.4.1.
Good to know. Thanks for the info. I appreciate all the work that
you and the rest of the developers do. Y'all ROCK! ;-)
Manager of System Operations
1580 Francisco Street, Ste. 101
Torrance, CA 90501
(310) 525-1600 ext. 628
Czar of all the Russias
Opinions are my own and do not necessarily reflect those
of the company. Viewer discretion is advised.
Please do not make any inferences about what is in this email
beyond what is stated. If there is any unclarity in this email,
please ask the author of the email for clarification. Any assumptions
about the content of this email or what it means are solely the
responsibility of the reader.
E Pluribus Unum. Annuit Coeptis. Novus Ordo Seclorum.
This message, together with any attachments, is intended only for the use of
the individual or entity to which it is addressed. It may contain
information that is confidential and prohibited from disclosure. If you are
not the intended recipient, you are hereby notified that any dissemination
or copying of this message or any attachment is strictly prohibited. If you
have received this item in error, please notify the original sender and
destroy this item, along with any attachments.