[OpenAFS] Re: Client Cache Question

[Andrew Deason]

On Mon, 24 Jun 2013 15:58:45 -0700
Timothy Balcer <timothy@telmate.com> wrote:

>    - Soon after client restart, rsync is very fast.. less than a second,
>    compared to rsync modules at 3-5 seconds
>    - Then, immediately, or after a few iterations, it slows down to 40+
>    seconds. It stays this way for the duration (days, so far. no change).
>    - Rsync times to rsync modules on the same destination host do not
>    change.
>    - The amount of data is small, as is the number of files (100k or less
>    per file, and 100 or so files each time)
>    - The files are always new. They are not maintained on AFS, they are
>    sync'd TO AFS from a standard file system. They are never there already.
>    - Network speeds are good

So if I understand correctly, you're running rsync ./some/dir
/afs/some/dir; that is, rsync to the local machine, into /afs (and the
afs volume is somewhere far away). And you're comparing this to running
'rsync ./some/dir server::foo', where the destination server is the afs
fileserver, or close by it? And each rsync run is for different data,
but around the same size each time.

Some kind of trace could help say what's going on. I mentioned fstrace
before, but something that's easier to get and probably more
interpretable by you would be just a plain strace. If you run with -T,
you'll get the amount of time for each syscall, so you could see if
we're hanging on some specific operation. (also probably run with -f,
and -o /path/to/file to save the output)

Or run rsync with --progress, which could maybe show if we're hanging on
a specific file or something. I think of that as more for interactive
use, though; if you're keeping this to a more noninteractive batch
process, I'm not sure if that's useful at all.

-- 
Andrew Deason
adeason@sinenomine.net