[OpenAFS] clarification on client caches

[Wes Chow]

> > May have been covered elsewhere in thread and if so oh well:  are you
> > filling the cache until it purges?  I.e. did you initialize a 50 GB
> > cache (in which case a huge number of Vfiles are created and you have to
> > be careful, at the least, with # of inodes on cache partition); or, did
> > you initialize and 50 GB cache and write into it until the cache begins
> > to purge?

Some more information...

My cacheinfo file has a 50000000 as the cache size.  Here are my afsd
options:

"-stat 4000 -dcache 4000 -daemons 6 -volumes 256 -files 50000
-chunksize 19"

Using a completely fresh cache, I started to cat about 50 gigs of
files (the files are 1 gig each).  At the same time, I ran "fs
getcacheparms" every 5 seconds. It reaches:

AFS using 4078084 of the cache's available 50000000 1K byte blocks.

And then afs_cachetrim runs and that number of used blocks decreases
to about 100,000.  (It's actually more like 4.5 million blocks, the
example I pasted above hadn't started trimming yet)

As a test, I decided to stop the cats when it reached 4,000,000 and
count the number of empty V files versus populated V files and
resulted in this:

base:/var/cache/openafs# find -type f -iname "V[0-9]*" -exec ls -l {} \; | awk '{ if ($5 == 0)
zero++; else other++; } END { print zero, other }'
42034 7966

42034+7966 = 50,000
7966*(2^19) = 4176478208  (the chunk size is 19)

Both of these results make sense.  What doesn't make sense to me is
why afsd is deciding to trim the cache when only about 8000 of the V
files have been populated.

If I understand the AFS cache algorithm correctly, afsd shouldn't
attempt to purge any cache that still has enough V files to satisfy a
read request.  Is that right?

Except for the underusage of the cache, the machine appears to be
operating properly (no hangs, no slowdowns, no kernel panics, etc).


Wes

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