On Tue, 25 Jun 2013 13:49:06 -0700 Timothy Balcer <[email protected]> wrote:
> So, this means that there is no networkly or I/O reason on the > destination or source that could be the culprit particularly. That's not necessarily true; even discarding the issues with Rx (the transport protocol AFS uses), some networking issues can be UDP-only, which would affect AFS but not straight rsync. You may find that very unlikely, and I certainly try not to jump straight to that conclusion right away, but it has happened before. > Im running an fstrace right now, but as you said, its very cryptic. Yeah, I meant that for an fstrace you'd need to give it to an openafs developer (give it to me, or to the list, or whatever). That would contain filenames and volume names, but not file data. > Are you suggesting I run an strace on the rsync process? Or that I > attach a strace to all the afs background daemons? Just strace the rsync process. Just to see if we're slow on, say, open/write/close, or something you may not expect, like lstat or getdents or something. That would also tell you if a specific file is slower than all of the others. Before we can look at what it is within AFS that's making things so slow, it would help to know what operation is actually being slow. Obviously if you share the raw strace output with someone, that would contain path names and a little bit of the file data. I was intending for you to look at that and see if anything is unusual, or just report what seems "slow". -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
