[OpenAFS] cache performance

[Phil.Moore@morganstanley.com]

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

Nathan> Have you considered using the -syslog log mechanism, or are
Nathan> you running on a platform with a syslogd that can't handle
Nathan> heavy loading.

I think that option post-dates my hands on administration of AFS :-(

That's worth looking into.  In my experience, syslogd can take a
pretty heavy beating, so I would think that's not a problem.   

Phil> I'm also worried about the volume of information that would be
Phil> generated into the FileLog, which should be the place to look for
Phil> problem diagnostics, which you don't want to hide among a cloud of
Phil> performance/usage statistics.

Phil> I think a better mechanism would be to have the fileserver maintain
Phil> this information in memory, and to query it (and reset it)
Phil> periodically, via a new RPC.  Then, I can ask for this data as often
Phil> as I want, once a day, or maybe once an hour, if I need to do finer
Phil> grained analysis.

Nathan> Yeah, that's what Derrick and I were thinking, something similar in
Nathan> nature to fstrace.

However, I want to architect the mechanism to be a bit more manageable
and robust than a debugging tool, and most importantly, we need to
minimize the performance impact, of course.

Phil> [*] Bonus question: anyone know where I'm getting these timestamps?
Phil> I'll bet you can't guess...

Nathan> dayUseDate?

Bingo -- unfortunately, this isn't printed by "vos examine", or any
vos command at all.  I had to write an new daemon for the bosserver:
rvolinfod.   You can probably guess how it works.   

rvolinfo (the client) talks to rvolinfod (the server) to remotely run
volinfo commands, and this lets me write code that queries the entire
AFS cell for volume header information, which I can then slice and
dice anyway I want.

For RO volumes, you just take the maximum value of the dayUseDate, and
you have a lastaccess timestamp for the volume.