On 1/22/2014 2:25 PM, Andrew Deason wrote: > 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.
Coming back to this discussion of where two hours comes from. In the Windows cache manager all cm_cell->vlServer lists have a time to live associated with them. If the list is populated from DNS, the DNS query TTL is used. If the entry is populated from the Windows registry or the CellServDB file, then a TTL of 7200 seconds (two hours) is assigned. At the end of two hours the vlServer list will be destroyed and the cell's vlserver list will be rediscovered. This logic is in src/WINNT/afsd/cm_cell.c cm_UpdateCell(). Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
