[OpenAFS] cache performance

[Phil.Moore@morganstanley.com]

>>>>> "Nickolai" == Nickolai Zeldovich <kolya@MIT.EDU> writes:

Nickolai> Well, I thought this was the behavior for a long time now, but since
Nickolai> you mention it, hm...  It looks like in 3.5p2, Transarc added noatime
Nickolai> code to the Solaris port (osi_DisableAtimes() in SOLARIS/osi_file.c),
Nickolai> and to Linux (in osi_UFSOpen() in LINUX/osi_file.c).  But something
Nickolai> seems to be still updating the atimes, as I'm seeing recent atimes
Nickolai> on most V files in my AFS client caches.

Nickolai> So, although there's code that claims to disable atimes, empirical
Nickolai> evidence suggests that it's broken, and atimes are being updated
Nickolai> anyway (not a big surprise for Transarc/AFS code).  Given that you
Nickolai> are relying on atimes, I'm a bit hesitant to "fix" it, esp. lacking
Nickolai> good performance reasons to do so.

It would not be the end of the world if we lost this functionality,
and given the weak performance of the AFS client (generally,
anecdotally speaking) anything that improves performance would most
likely be the right trade off.

>> The reason we have this code is that we analyze the contents of ALL of
>> our clients caches (yes, I'm not joking, we really do), and procude
>> enterprise wide reports on who is accessing what volumes.  This has
>> proven very useful.

Nickolai> Would a combination of cmdebug and server-side logging be a
Nickolai> reasonable alternative?

Well, what I really want is a way to cleanly extract this inforamtion
from the servers.   Any audit that depends on automated tasks running
on clients is guaranteed to NOT give you 100% coverage.   

The server's the right place to do this, of course, and eventually, we
want to look into significantly enhancing the server side client
statistics, and the mechanisms for extracting them.

If I have to audit the client, I don't care *how*, provided I can get
at the necessary information.  If cmdebug can give me a comprehensive
summary of what volumes are in the cache, I'll rewrite our code.