[OpenAFS] cache performance

Nathan Neulinger nneul@umr.edu
29 Oct 2002 22:06:01 -0600


On Tue, 2002-10-29 at 21:44, Warren.Yenson@morganstanley.com wrote:
> > On Tue, 2002-10-29 at 21:06, Lester Barrows wrote:
> > > Whenever a file is accessed on the client, I believe it contacts the cache
> > > manager to ensure that it hasn't changed. Perhaps the cache manager, rather
> > > than the file server, would be the most authoritative place to collect this
> > > information.
> 
> On 29 Oct 2002, Nathan Neulinger wrote:
> > The cache manager is part of the client. So, yes, it is contacted.
> >
> > As long as a callback is still present with the server, there shouldn't
> > be any communication with the file server.
> >
> > So, one possible solution would be a cache manager debug set (fs setset)
> > that had a very minimal amount of logging generated - to where you could
> > reasonably run fstrace regularly on clients. i.e. not a full bore -
> > every access, just file opens.
> 
> The problem that Phil alludes to is not to get the most short term,
> up-to-date information, but over the course of a day, to get the access
> times of all volumes accessed by the client.
> 
> Since callbacks are 30 minutes for read-write files, and 2 hours (or
> thereabouts) for read-only volumes, surely the client will contact the
> server sometime during the 24 hour period we are interested in.  As the
> callback expires, the client has to send a FetchStatus to renew / extend
> the callback, which the server can record.  This is why Phil would like
> that fact recorded in the server.

Ah, well that seems simple enough. I think it would be relatively
trivial to add additional standard logging to the file server, although
I wonder if a Rx based logging mechanism similar to fstrace might be
more useful.

Thoughts?

> This is still more authoratative for our purposes as there number of
> clients is in the order of thousands (to tens of thousands) but the number
> of servers is in the low hundreds.  We also control the builds on the
> servers much, much more tightly, and can ensure that the audits run and
> complete successfully.

Out of curiosity, would y'all be willing to share some details of your
architecture?

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216