[OpenAFS] clarification on client caches

[Wes Chow]

> Case 1: If I start with the cache size I want and "-chunksize 20" as
> the only afsd option, after afsd finishes creation of the cache,
> afs_cachetrim then proceeds to use up most of the CPU in what appears
> to be an infinite loop.  I've let it run for about 4 hours and it
> never stopped.  Accesses to /afs work, but the computer is
> understandably slow.
> 
> Case 2: What I'm doing now is limiting the number of V files by using
> the "-files 50000" option.  If I start it out at the cache size I want
> (30 gigs), accesses to /afs hang without afs_cachetrim running amok.
> However, if I lower the cache size it seems to work.  Starting at a
> lower cache size and resizing upwards doesn't seem to help.

The plot thickens...  a CentOS client (a rebuild of Redhat Enterprise
3) can create a client cache of 50 gigs fine.  A Debian client with
the same size cache and same options to afsd seg faults.  Both were
using MEDIUM parameters.

A Debian client initialized with a 500 meg cache and MEDIUM parameters
starts up fine.  A cache resize upwards to 50 gigs then seems to work.
I never see afs_cachetrim appear in top (though my delay is set low),
and the machine seems usable.

I'll try a couple more variations to see if I can get more specific
information.

Also, does it matter which gcc was used in compiling the kernel?  The
Debian client is using a custom compiled 2.4.27 kernel with gcc 3.3.
The Centos kernel is 2.4.21-9.0.1.EL.c0smp.  I don't know which
compiler it was built with.

Wes

-- 
http://www.woahnelly.net/~wes/          OpenPGP key = 0xA5CA6644
fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 6644