On 1/22/2014 12:59 PM, Andrew Deason wrote: > For as long as I can remember, whenever someone asks how long the client > caches VLDB information, the answer given is that we just cache it for a > fixed 2 hours interval. Recently I've realized I don't actually know > where in the code this happens, so I wasn't sure if I just forgot this > information, or if I never actually knew and was just trusting/parroting > what everyone said.
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. Even Brandon's response to Prochazka in the disconnected mode thread said "about 2 hours". The Windows cache manager will reset the volume location information for many reasons and will do so on different time frames depending upon the state of the data which the VL server returned. The Windows CM unlike the UNIX cm pays attention to the NEW-SITE/OLD-SITE flags and will not use out of date sites. If a mixed set of old/new sites were received the cache manager queries the VL server for that volume approximately every five minutes until all of the sites are consistent. There are other complexities for example the cache manager resets the volume location information when a file server in response to VNOVOL and VMOVED errors. 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. It is worth noting that the OpenAFS 1.0 Windows cache manager did have a fixed two hour event in the daemon thread that discarded all data for all volumes once every two hours. Discarding volume information on a per volume basis is something that came much later. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
