Re: Another rfe: "cp" this time

[Pádraig Brady]

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.