On Sat, 24 Mar 2012 02:59:19 +0200 (EET) jukka.tuomi...@finndesign.fi wrote:
> Thanks for the help, I got it working now > > -chunksize 23 transfer speeds: > > 20M/2000 files: > > SSH to AFS ~150KB/s > AFS to SSH ~285KB/s To be clear, none of the suggestions given were intended to improve this case. iirc, it is likely that this is just how fast AFS is going to go with such little files and that level of latency (Jeffrey already provided a more in-detail explanation). There is not much you can do about that; filesystems don't usually perform very well with lots of little files written in sequence. > 109M single file: > SSH to AFS ~533KB/s > AFS to SSH ~840KB/s > > 109M to AFS seems to actually hang in the end. In nautilus it shows as > if ok, but when it reaches 100% the dialog doesn't go away (have to > kill the process). It could be reading the file into RAM and writes it > to disk afterwards, or something. This wasn't just with the changed > chunksize. When you write a file to AFS, you are actually writing to the cache on the local client until you close the file (or run fsync()). So, what is probably happening is that that graphical file progress dialog thing is showing progress when we write() the contents, but that last part is when nautilus is calling close(), which will take a while since we need to write the data to the fileserver. Nautilus may not a good program to be using to determine how fast file transfers are going. Using either: dd if=/path/to/src of=/path/to/dst or time cp /path/to/src /path/to/dst on the command line is probably a better way to see this; they will allow you to easily calculate the overall rate of the transfer after it is finished. > > If it still seems slow no matter what you try, what may be helpful is if > > you can provide the output of: > > > > rxdebug <client> 7001 -rxstat -noconn > > rxdebug <server> 7000 -rxstat -noconn > > > > So we could see the rate of resends and such for Rx. Provide that output > > both immediately before and immediately after you try a transfer. > > I hope this helps The rate of resends from the client to the server seems a bit high, along with the rate of dup packets on the server side. I'm not sure at the moment if this is just then a result of the quality of the client network... or maybe Rx just handles out-of-order packets or latency spikes poorly. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
