copy chunk preliminary results

Steve French smfrench at
Thu Nov 21 05:31:56 MST 2013

On Thu, Nov 21, 2013 at 5:20 AM, Christoph Hellwig <hch at> wrote:
> On Thu, Nov 21, 2013 at 11:45:41AM +0100, David Disseldorp wrote:
>> It depends on how the SMB server interprets the copy-chunk wire request.
>> On Btrfs, Samba can translate the request into a BTRFS_IOC_CLONE_RANGE
>> ioctl, in which case the same CoW semantics are observed[1]. See:
>> By default however, Samba (and Windows) will perform the copy on the
>> server-side using regular reads/writes. A generic cp --offload or
>> similar would probably make more sense on the client side.

On copychunk Windows server is clearly doing the equivalent of reflink
so this isn't just Samba/btrfs.  I was getting performance more than 100 times
better using copychunk to Windows than doing copy with sending
reads/writes over the network.

> I don't think it really matters what the optimal case is, it matters
> what the worst case is.  Think about it - a reflink really just is
> a smart shortcut for copy + dedup, which a filesystem on the server
> could do anyway.
> On the other hand a user of cp --reflink expects it to be a quick
> operation.

My tests show that in every case the copychunk over SMB2/SMB3 mount is
much faster even in the worst case where it is emulated in Samba.

> So it's time folks finally get the damn copyfile system call in, use
> that for CIFS, NFS and co, as well as letting btrfs optimize it.

I agree that the copyfile system call would be a big help.



More information about the samba-technical mailing list