[OpenAFS] Re: OpenAFS failing rmdir performance

[Andrew Deason]

On Fri, 08 Oct 2010 23:03:11 +0200
Matthias Braun <matthias.braun@kit.edu> wrote:

> The first few rmdirs are fast after that it takes around a second or
> so per rmdir... This does only happen for non-empty directories. Is
> there a conceptual problem in AFS for this or is this a strange kind
> of bug?

This is probably the throttling behavior of the fileserver, where the
fileserver throttles client activity if it sends too many RPCs that
return error codes in a certain amount of time. You can see if this is
happening by looking at the output of 'rxdebug <fileserver> -rxstats',
specifically the 'packets sent' line where it says 'abort <number>'. Or
look at 'rxdebug <client> 7001 -rxstats' and look at the 'packets read'
line. The abort count should go up for both when you try to rmdir such a
directory.

If you have control over the fileserver, you can turn this behavior off
with '-aborttreshold 0' (or set it to a higher value than the default of
10).

This is sort-of a bug, since the client could probably avoid talking to
the fileserver at least some of the time by checking if the cache
contains anything in the directory you're trying to rmdir. It's not
avoidable all of the time (unless we spend the extra time to read the
dir contents from the fileserver), but right now I don't even think we
try. I think it would be worth it to try doing that, since it avoids
hitting the net.

-- 
Andrew Deason
adeason@sinenomine.net