We run two very big CAD/CAM applications (SDI Unigraphics, SDRC I-DEAS)
on our DECstations, which run dataless, (e.g. local disk with a minimal
root, 200Mb page/swap, 70Mb AFS cache, ~15Mb temp space). The binaries
are huge (up to 38 Mb!!), partly because of Ultrix's non-support of
shareable libraries, and on our DECstations, the programs take a fair
old time to start up.

When I originally set up AFS, I tried to start up these apps after
having emptied the local workstation cache (fs setcache 1; fs setcache
70000), and then again a second time with a newly updated cache.
Brilliant. With an emptied cache starting I-DEAS takes about 4.5
minutes. A subsequent startup takes about 55 seconds, not noticeably
slower than with the software installed on a local filesystem.

What I DIDN'T do (and a colleague has just done) is try the same
experiment with a fragmented) cache. This gave us a nasty shock. On a
well-used random workstation, starting I-DEAS takes (again) about 4.5
minutes. OK, having got it cached, now what? 4.5 minutes again. In
fact, subsequent startups seem to take about 10 seconds LONGER, though
that's well within experimental error.

Zeroing the cache resulted in another 4.5 minute startup, but the next
time, we were back down to under a minute (so we haven't got bad
hardware, for instance). It seems that AFS caching works well for big
files only when they are contiguous in the cache (or at least minimally
fragmented). I've been extolling the virtues of disk caching on the
basis that files surviving in the cache across reboots is a GOOD thing.
Now, it seems not so.

So - is there such a thing as an AFS cache defragmenter? Is the local
file system fragmentation at fault? Or can I improve matters
significantly with cache parameters? Increasing chunk size may be a
possibility, but I don't want to adversely affect small files (which
do, after all, constitute the vast majority of file traffic). If not,
then we'll start zeroing the cache on reboot (all workstations are
rebooted daily or weekly). However, this seems wasteful, given that the
stuff in the cache should indeed be there - but just not so fragmented.

Peter Lister                                    [EMAIL PROTECTED]
Computer Centre,
Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England    Fax: +44 234 750875

Reply via email to