On Wed, 22 Jan 2014 13:52:22 -0500 Jeffrey Altman <[email protected]> wrote:
> When I refer to "2 hours" for the volume location information being > cached it is an approximate upper bound on how long a client might > continue using the data. I am certainly not describing the inner > complexities of the cache managers. Neither am I; the Windows explanation earlier is simplified to the same degree, but just pointing to specific parts in the code as I did so. > The Windows cache manager will reset the volume location information for > many reasons Yes, I mentioned there are other conditions where the entry is reset; they aren't relevant. (All of those cases cause the entry to be potentially reset _more_ frequently than once per hour.) > The one hour default lifetime for the daemon thread is an > approximation because the deaemon thread does a lot of different jobs > and some of them can block for extended periods of time. Yes, it's an approximation. So, "approximately 1 hour" sounds like an accurate description; certainly more accurate than "approximately 2 hours". If that background thread is delayed by an hour, that seems like an extraordinary event; as far as I can tell, this is the same thread in which we check for servers coming back up, for callback expirations, etc etc. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
