[OpenAFS-devel] Re: tweaking openafs configuration - chunksize, cache expiration and cache renewal

[Andrew Deason]

On Sat, 17 Apr 2010 15:56:49 -0400
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> (2) The data is stored in the cache but the callback registrations
>     expire in a few minutes when a read/write volume is being used.
>     If a readonly volume is being used, then the callback
> registrations expire in a couple of hours.

...but note that this shouldn't require fetching all of the data again,
which is what Stephen seems to be inferring. Subsequent accesses should
still be much faster (depending on the size of the file).

Unless the file actually changed, or the cached data got kicked out of
the cache, etc etc.

And RW callbacks can last hours or minutes, depending on the number of
accessors (sorry, nitpicking).

> 
> (3) The default configuration of the file server is not very good.
>     I recommend:
> 
>       -L -udpsize 131071 -sendsize 131071 -rxpck 700 -p 128 -b 600
>       -nojumbo -cb 1500000
> 
>     You can remove -nojumbo if you know it is safe to send large udp
>     packets and not have them be fragmented between your various
> sites.

Note that -nojumbo is the default in recent server versions, and you
need to specify -jumbo to get the jumbogram benefits and/or problems.

> > Lastly, how do you guys think about the general plan - setting up an
> > afs-configuration that caches entire afs volumes from a designated
> > cell once a day or something... is this really practically or
> > rather not recommended due to performance issues?

You may be interested in the potential cache-pinning feature of the
client. That doesn't really help you right now as it's not complete yet,
but it's something to keep in mind in the future, if you're still
thinking about this.

> I'm not comfortable that you have determined the actual cause of
> the performance delays.  You may want to monitor the traffic flows
> with wireshark and see what is actually being sent and received on
> the wire.

+1

-- 
Andrew Deason
adeason@sinenomine.net