copy chunk preliminary results

[Pádraig Brady]

On 11/04/2013 06:30 AM, Steve French wrote:
> I extended my initial copy chunk kernel client patch to handle files >
> 1MB (repeating copychunk requests multiple times, 1 chunk at a time, I
> realize that this will be even faster when I send more than 1 chunk at
> a time)
> 
> Preliminary results local loopback mount of current cifs kernel code
> (vers=3.0) to Samba (master branch, running on Fedora 19 with btrfs):
> 
> File size of test file (vmlinux.o) was 373987044 bytes
> 
> Over the network Copychunk (refcopy) was about six times faster than without.
> ane even local copy (no reflink) is slower than remote copy with
> reflink.  Copychunk would look even better except that the server disk
> is SSD.
> 
> 
> [sfrench at pc-on-right cifs-2.6]$ time cp vmlinux.o ~/trgt-1-local
> real    0m0.769s
> user    0m0.002s
> sys    0m0.502s
> 
> (Local copy with reflink is amazingly fast on btrfs)
> [sfrench at pc-on-right cifs-2.6]$ time cp --reflink vmlinux.o
> ~/trgt-2-local-reflink
> real    0m0.004s
> user    0m0.001s
> sys    0m0.002s
> 
> (remote copy with reflink to Samba was six times faster than remote
> with no reflink, similar results when repeated)
> [sfrench at pc-on-right cifs-2.6]$ time cp --reflink
> /mnt/cifs-2.6/vmlinux.o /mnt/trgt-3-remote-reflink
> real    0m0.416s
> user    0m0.000s
> sys    0m0.029s
> 
> 
> [sfrench at pc-on-right cifs-2.6]$ time cp  /mnt/cifs-2.6/vmlinux.o
> /mnt/trgt-3-no-reflink
> real    0m2.596s
> user    0m0.007s
> sys    0m0.860s

So cp --reflink has CoW semantics and so probably not an
appropriate interface for this.  Unless I'm misunderstanding,
this SMB copy offload does result in a normal copy on the server right?
So that would imply that cp should try to use the "smb_copy_offload"
ioctl unconditionally after a little introspection, or preferentially
this would be encapsulated in the recently mooted copyfile() level
kernel call, which cp etc. could just call to do the operation.

thanks,
Pádraig.