"Peter Lister, Cranfield Computer Centre" <[EMAIL PROTECTED]> writes:
> > what version of AFS cache manager are you running, and what switches
> > do you use for afsd?
>
> 3.2 and no switches
There is a bug in AFS versions 3.2 and earlier which depends on the
relationship between the number of chunks in use in one's cache, and
the number of dcache structures which the cache manager uses to manage
chunks. As the latter increases relative to the former, the cache
replacement algorithm becomes less and less effective. In the worst
case, it becomes almost MRU. This bug was rarely encountered prior to
3.2, but 3.2 changed the default allocation of dcache structures.
This is almost certainly the cause of your observed performance
anomaly.
We discovered this bug very late in the 3.2 release cycle (right
before tape duplication), so the only safe fix was to modify the
settings in the supplied rc.afs scripts in such a way as to avoid the
bug. The bug was fixed in AFS 3.2a, and the defaults are once again
safe to use.
Dave Stephenson sent a letter to all the site contacts explaining
the problem and the solution. Evidently, some administrators aren't
site contacts, or there was some other communications failure, as
several admins have encountered the same problem.
The recommended solution is to upgrade to the latest pull release
version of AFS. A temporary workaround would be to specify -dcache on
the afsd command line, using a lower value than the default. For
instance, 300 should be safe.
Lyle Transarc 707 Grant Street
412 338 4400 The Gulf Tower Pittsburgh 15219
