Not precisely: I am rsyncing from some files in a directory local to the AFS client, into the afs tree, and ALSO from that same local directory, the same files, to an rsync module. These occur sequentially.. they don't run in parallel.
The rsync server lives on the same physical machine the AFS fileserver lives on. So, this means that there is no networkly or I/O reason on the destination or source that could be the culprit particularly. Im running an fstrace right now, but as you said, its very cryptic. Are you suggesting I run an strace on the rsync process? Or that I attach a strace to all the afs background daemons? Best, On Tue, Jun 25, 2013 at 12:14 PM, Andrew Deason <[email protected]>wrote: > On Mon, 24 Jun 2013 15:58:45 -0700 > Timothy Balcer <[email protected]> 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 > [email protected] > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Timothy Balcer / IT Services Telmate / San Francisco, CA Direct / (415) 300-4313 Customer Service / (800) 205-5510
