copy chunk preliminary results

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


On Thu, Nov 21, 2013 at 5:20 AM, Christoph Hellwig <hch at infradead.org> 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:
>>
>> https://wiki.samba.org/index.php/Server-Side_Copy#Btrfs_Enhanced_Server-Side_Copy_Offload
>>
>> 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
internally,
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.

-- 
Thanks,

Steve


More information about the samba-technical mailing list