The handle count will go down over time after the pages have not been touched for a while.
In order for this to happen you must stop accessing the AFS file system. The number of
handles which are allocated is slightly above
<total cache memory> / <cache block size>
If you use a large amount of memory and a small block size this number can be exceedingly
large.
There is no bug here, it is simply an extremely poor design for the cache sizes which are
desired. The cache manager needs to be replaced. The existing algorithm simply results
in huge quantities of thrashing when the cache is filled.
Jeffrey Altman
Rodney M Dyer wrote:
Jeffrey and others,
Today I've found a way to easily reproduce the bug in the AFS Windows cache manager. It shows up rather easily as a leak in the handle management. The number of handles rises out of control as files are being copied from AFS to the local disk. After the number of handles has risen beyond what is expected, if you run an application from AFS, then the startup time will take much longer than normal. For example, our ProE application starts up in 40 seconds avg. starting with an empty 8192 Meg cache, but after the bug is reproduced, the time climbs to over 2 minutes.
smime.p7s
Description: S/MIME Cryptographic Signature
