[OpenAFS] cache performance

[Phil.Moore@morganstanley.com]

>>>>> "Nathan" == Neulinger, Nathan <nneul@umr.edu> writes:

Nathan> At one point, I was considering trying to merge the cache
Nathan> debugging tools with fs, to add a root-only "fs dumpcache"
Nathan> command.

Nathan> Not sure if this would be an ideal way to go about it. 

Ideal?  Neah, but I've long ago given up on the ideal solution.   I
just want a working one ;-)

Seriously though, dump_afscache was *never* a fully integrated and
respected debugging utility in the product.  You had to beg Transarc
to give it to you (wasn't part of the product distribution), even
though it was essential for debugging cache problems.  I beleive the
same was true for kdump.  A quick scan of the openafs source tree
suggests that we at least install this thing by default now.

Personally, I'd like to see the debugging tools improved, since we use
them for more than just problem diagnosis.  We also use them for
statistical analysis of system usage and performance.  

I already alluded to our cache audits (which, although expensive in
terms of disk space, CPU, and data management, have proven to be a
very powerful tool), but I beleive that capacity planning is one of
the hardest problems we have to solve, and you can only get a handle
on that problem with good performance and usage statistics, maintained
historically, and analyzed agressively.

You can only do good capacity planning when you have good performance
and usage stats, and code that uses kdump, dump_afscache, and their
ilk to accomplish this is hackery at best.

The good news is that we (Morgan Stanley) need this stuff so bad,
we're willing to fund some of the development (when all of you fine
people don't do it for us for free ;-), and in case you're paranoid,
*OF COURSE* the result of what we fund go back into the OpenAFS code
base.