On 05/01/2012 05:15 AM, H. Peter Anvin wrote: > On 04/27/2012 08:35 AM, Pádraig Brady wrote: >> >> Yes, cp is bad for high latency links as it has a >> 32KiB buffer which it serially reads to and writes from. >> > > Why this that, though? At least for file-to-file copy, it could > certainly do much better with mmap() + write(). > > 32K is so 1990.
Well 2009 which is when we changed from 4K (blksize) :) Just yesterday we bumped to 64K to minimize system call overhead, which on modern machines give another 10% speed increase when copy files from cache. Though it should be emphasised that the bottle neck is usually in the devices/network and so optimizations at this level do not help in the general case, and your point about avoiding the copy (with mmap) is a good one, but in the same camp. We have looked at higher level constructs to improve efficiency. fiemap() to avoid reading holes or empty extents from input. However XFS needs to sync a file first before fiemap is representative, so we only enable that functionality for sparse files. ext4 also has some issues with this currently, but could be adjusted I understand. We also looked into using fallocate to optimize writing NULs to the output, as well as improving extent layout in the dest, and giving immediate ENOSPC. Again XFS is problematic here as it has overloaded fallocate() to align any allocations on 1MB (configurable) boundaries, which introduces fragmentation if used generally. We could restrict fallocate() to large files I suppose. I'm also inclined to adjust fallocate() in the kernel to accept a FALLOC_FL_ALIGN flag, that xfs tools could use to enable this functionality. cheers, Pádraig.
