On 2/8/2019 2:37 PM, Andreas Dilger wrote: > On Feb 8, 2019, at 8:19 AM, Steve French wrote: > >> Current Linux copy tools have various problems compared to other >> platforms - small I/O sizes (and not even configurable for most), >> > Hmm, this comment puzzles me, since "cp" already uses s_blksize > returned for the file as the IO size? Not sure if tar/rsync do > the same, but if they don't already use s_blksize they should. > But not as the optimal IO size. It returns 4K. My RAID can write 12 disks in parallel or 48K.\ Running cat for example. Yet the optimal bytes get returned as 4K. cat speed: /bin/time cat 4G 4G 4G 4G > 16G 0.17user 10.06system 1:52.84elapsed 9%CPU (0avgtext+0avgdata 8876maxresident)k 0inputs+0outputs (2230major+0minor)pagefaults 0swaps Note, the 4G is copied 4 times, so really only a need to read 4G once so read 4G+write 16G = 181MB/s in those cases look like cat is averaging about 290M/s(?) cp is doing 16 read and write in 230MB/s vs. using 'dd': bin/iotest Using bs=16.0M, count=64, iosize=1.0G R:1073741824 bytes (1.0GB) copied, 1.41419 s, 724MB/s W:1073741824 bytes (1.0GB) copied, 3.79678 s, 270MB/s dd is using a 16M bufferl Optimal is about 32M buff, in all cases the utils read and wrote to the network. No figure gives you back that you should use 16M This is on Win7SP1x64 over 10Gb ethernet using 4.20.3 kernel and some 4.x samba version. I can't even find the physical IO size in /sys or /proc (sda uses all 4K-sec disks). So.....you won't get more than about 20-30% on reads. Note it will take some work to put together a real test with cp. cp used to be the fastest -- now it's not (I think they walk the tree twice). Anyway, have been doing speed tests between Win+lin since XP days. Double Note: The 'dd' test is only testing network xfer speed (no file I/O) as it copies from /dev/zero and outputs to /dev/null on the far end.