[PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
Hi,

Please find attached a patchset from Aurélien and myself, which adds
support for FSCTL_DUPLICATE_EXTENTS_TO_FILE - a new reflink/clone FSCTL
supported on Windows Server 2016 shares backed by ReFS.

A couple of things that I'm still a little unsure about:
- It might be cleaner to move the locking calls out of the copy-chunk
  VFS function (drop VFS_COPY_CHUNK_FL_IGNORE_LOCKS), and move them
  into fsctl_srv_copychunk_loop(). Thoughts?
- The server behaviour for success on truncated clone (where the
  dest file's allocation size is less than the size of the clone) seems
  prone to races, especially given that the operation ignores locks.
  + See test_ioctl_dup_extents_len_beyond_dest(). Dochelp are aware of
    this inconsistency.
  + There's not much we can do here, as we need to match Windows Server
    2016 + ReFS behaviour.

Feedback appreciated.

Many thanks to the Microsoft Protocol Open Specifications Team for
clarifying a number of doc/wire inconsistencies.

Cheers, David

dup_extents_xp2017.patchset (54K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
Not directly related to the patch, but IOC_CLONE_RANGE is a core
VFS feature in Linux these days and for example support by XFS and NFS
as well.  It's somewhat odd to have it in a vfs_btrfs module.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Thu, 4 May 2017 08:40:00 -0700, Christoph Hellwig wrote:

> Not directly related to the patch, but IOC_CLONE_RANGE is a core
> VFS feature in Linux these days and for example support by XFS and NFS
> as well.  It's somewhat odd to have it in a vfs_btrfs module.

Yeah, this'll hopefully get moved out of vfs_btrfs soon. A WIP
syscall(SYS_copy_file_range) patch from Björn is available at:
https://lists.samba.org/archive/samba-technical/2017-January/118259.html

Cheers, David

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Thu, May 04, 2017 at 05:54:41PM +0200, David Disseldorp wrote:
> On Thu, 4 May 2017 08:40:00 -0700, Christoph Hellwig wrote:
>
> > Not directly related to the patch, but IOC_CLONE_RANGE is a core
> > VFS feature in Linux these days and for example support by XFS and NFS
> > as well.  It's somewhat odd to have it in a vfs_btrfs module.
>
> Yeah, this'll hopefully get moved out of vfs_btrfs soon. A WIP
> syscall(SYS_copy_file_range) patch from Björn is available at:
> https://lists.samba.org/archive/samba-technical/2017-January/118259.html

Don't use copy_file_range if you want to clone.  IOC_CLONE_RANGE is
always the better choice if supported.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
Hi David,

nice work! Some nitpicks below...

On Thu, May 04, 2017 at 05:30:35PM +0200, David Disseldorp via samba-technical wrote:
> Please find attached a patchset from Aurélien and myself, which adds
> support for FSCTL_DUPLICATE_EXTENTS_TO_FILE - a new reflink/clone FSCTL
> supported on Windows Server 2016 shares backed by ReFS.
>
> A couple of things that I'm still a little unsure about:
> - It might be cleaner to move the locking calls out of the copy-chunk
>   VFS function (drop VFS_COPY_CHUNK_FL_IGNORE_LOCKS), and move them
>   into fsctl_srv_copychunk_loop(). Thoughts?

Yeah, probably makes sense, but I'd have to take a closer look. As I'm going to
do some larger changes here in the near future for offload read/write as, I can
move the locking stuff around as part of that.

> - The server behaviour for success on truncated clone (where the
>   dest file's allocation size is less than the size of the clone) seems
>   prone to races, especially given that the operation ignores locks.
>   + See test_ioctl_dup_extents_len_beyond_dest(). Dochelp are aware of
>     this inconsistency.
>   + There's not much we can do here, as we need to match Windows Server
>     2016 + ReFS behaviour.

ok.

[PATCH 03/10] vfs: add parameter to copy chunk VFS function to handle dup_extents

TODO: please move "[[hidden email]: split VFS API change from  ioctl code]" to subject body

otherwise rb: me.

[PATCH 4/10] smbd/smb2_ioctl: add support for FSCTL_DUPLICATE_EXTENTS_TO_FILE

- initialize all pointer vars to NULL
- use DEBUG helper macros DBG_ERR, DBG_INFO, ...
- fsctl_dup_extents_send/recv() must create a tevent_req and return that
  and not just return the SMB_VFS_COPY_CHUNK_SEND subreq
- empty line between var declaration and subsequent first statement

Everything else: reviewed-by: me.

Fwiw, I tested copy behaviour of a Windows 10 client against Windows 2016
sharing a refs filesystem, as discussed last week. What I see is:

- server returns FILE_SUPPORTS_BLOCK_REFCOUNTING in volume attributes

- copying a 100 MB file with c-c -> c-v in the same share

- client issues offload read ioctl

- server returns invalid device request

- client falls back to copy-chunk

I don't see clone-range on the wire, trace attached. Am I missing something?

-slow

copy-file.pcapng.gz (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
Thanks a lot for the review, Ralph!

Please find a version 2 patchset attached. Further comments below...

On Sun, 7 May 2017 13:30:48 +0200, Ralph Böhme wrote:

> Hi David,
>
> nice work! Some nitpicks below...
>
> On Thu, May 04, 2017 at 05:30:35PM +0200, David Disseldorp via samba-technical wrote:
> > Please find attached a patchset from Aurélien and myself, which adds
> > support for FSCTL_DUPLICATE_EXTENTS_TO_FILE - a new reflink/clone FSCTL
> > supported on Windows Server 2016 shares backed by ReFS.
> >
> > A couple of things that I'm still a little unsure about:
> > - It might be cleaner to move the locking calls out of the copy-chunk
> >   VFS function (drop VFS_COPY_CHUNK_FL_IGNORE_LOCKS), and move them
> >   into fsctl_srv_copychunk_loop(). Thoughts?  
>
> Yeah, probably makes sense, but I'd have to take a closer look. As I'm going to
> do some larger changes here in the near future for offload read/write as, I can
> move the locking stuff around as part of that.
I've left it as is for now (with the flag).

> > - The server behaviour for success on truncated clone (where the
> >   dest file's allocation size is less than the size of the clone) seems
> >   prone to races, especially given that the operation ignores locks.
> >   + See test_ioctl_dup_extents_len_beyond_dest(). Dochelp are aware of
> >     this inconsistency.
> >   + There's not much we can do here, as we need to match Windows Server
> >     2016 + ReFS behaviour.  
>
> ok.
>
> [PATCH 03/10] vfs: add parameter to copy chunk VFS function to handle dup_extents
>
> TODO: please move "[[hidden email]: split VFS API change from  ioctl code]" to subject body
For the kernel this is a pretty common way of flagging changes which
have been made after an author (aaptel) has added his sign off:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n466
If Aurélien says that he's fine with the change as it is now, then I'll
drop the line completely.

> otherwise rb: me.
>
> [PATCH 4/10] smbd/smb2_ioctl: add support for FSCTL_DUPLICATE_EXTENTS_TO_FILE
>
> - initialize all pointer vars to NULL
> - use DEBUG helper macros DBG_ERR, DBG_INFO, ...
> - fsctl_dup_extents_send/recv() must create a tevent_req and return that
>   and not just return the SMB_VFS_COPY_CHUNK_SEND subreq
> - empty line between var declaration and subsequent first statement

I've added a SQUASH commit with these changes. If you and Aurélien are
okay with it then I'll squash it in.

> Everything else: reviewed-by: me.
>
> Fwiw, I tested copy behaviour of a Windows 10 client against Windows 2016
> sharing a refs filesystem, as discussed last week. What I see is:
>
> - server returns FILE_SUPPORTS_BLOCK_REFCOUNTING in volume attributes
>
> - copying a 100 MB file with c-c -> c-v in the same share
>
> - client issues offload read ioctl
>
> - server returns invalid device request
>
> - client falls back to copy-chunk
>
> I don't see clone-range on the wire, trace attached. Am I missing something?
Interesting, thanks for checking this. I've been using the cifs.ko
client until now. I don't know whether Explorer makes use of it at this
stage. Will try with robocopy.

Cheers, David

dup_extents_xp2017_v2.patchset (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Mon, May 08, 2017 at 02:22:11AM +0200, David Disseldorp wrote:
> Thanks a lot for the review, Ralph!
>
> Please find a version 2 patchset attached. Further comments below...

better, but now it has a memory leak. :)

Fix for that and an additional fixup attached.

> > > - The server behaviour for success on truncated clone (where the
> > >   dest file's allocation size is less than the size of the clone) seems
> > >   prone to races, especially given that the operation ignores locks.
> > >   + See test_ioctl_dup_extents_len_beyond_dest(). Dochelp are aware of
> > >     this inconsistency.
> > >   + There's not much we can do here, as we need to match Windows Server
> > >     2016 + ReFS behaviour.  
> >
> > ok.
> >
> > [PATCH 03/10] vfs: add parameter to copy chunk VFS function to handle dup_extents
> >
> > TODO: please move "[[hidden email]: split VFS API change from  ioctl code]" to subject body
>
> For the kernel this is a pretty common way of flagging changes which
> have been made after an author (aaptel) has added his sign off:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n466
> If Aurélien says that he's fine with the change as it is now, then I'll
> drop the line completely.
yup. But afaict for us the signed-off tag already implies the person worked on
the patch and they all jointly agree that the state of the patch is ok. So I
don't really see a need for this extra flag.

> > [PATCH 4/10] smbd/smb2_ioctl: add support for FSCTL_DUPLICATE_EXTENTS_TO_FILE
> >
> > - initialize all pointer vars to NULL
> > - use DEBUG helper macros DBG_ERR, DBG_INFO, ...
> > - fsctl_dup_extents_send/recv() must create a tevent_req and return that
> >   and not just return the SMB_VFS_COPY_CHUNK_SEND subreq
> > - empty line between var declaration and subsequent first statement
>
> I've added a SQUASH commit with these changes. If you and Aurélien are
> okay with it then I'll squash it in.
see above.

> > I don't see clone-range on the wire, trace attached. Am I missing something?
>
> Interesting, thanks for checking this. I've been using the cifs.ko
> client until now.

ah, ok. Which kernel version do I need? I have 4.10.13-200.fc25.x86_64

-slow

look.txt (48K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Mon, 8 May 2017 11:05:38 +0200, Ralph Böhme wrote:

> On Mon, May 08, 2017 at 02:22:11AM +0200, David Disseldorp wrote:
> > Thanks a lot for the review, Ralph!
> >
> > Please find a version 2 patchset attached. Further comments below...  
>
> better, but now it has a memory leak. :)

Ah, I take it you mean the free of the subreq before it's cleaned up by
the parent req. Following convention we should then also do the same in
smb2_ioctl_filesys_dup_extents_done().

> Fix for that and an additional fixup attached.

Looks good - please find one further patch attached, which I'll squash
in if you're okay with it.

...

> > > I don't see clone-range on the wire, trace attached. Am I missing something?  
> >
> > Interesting, thanks for checking this. I've been using the cifs.ko
> > client until now.  
>
> ah, ok. Which kernel version do I need? I have 4.10.13-200.fc25.x86_64

It went in with 02b1666544c08e245cb4e2253ed575f8128943d6, which was
first carried in 4.2, so cp --reflink should trigger it on your system.

Cheers, David


0001-SQUASH-further-minor-cleanups-following-Ralph-s-revi.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Mon, May 08, 2017 at 04:01:16PM +0200, David Disseldorp wrote:

> On Mon, 8 May 2017 11:05:38 +0200, Ralph Böhme wrote:
>
> > On Mon, May 08, 2017 at 02:22:11AM +0200, David Disseldorp wrote:
> > > Thanks a lot for the review, Ralph!
> > >
> > > Please find a version 2 patchset attached. Further comments below...  
> >
> > better, but now it has a memory leak. :)
>
> Ah, I take it you mean the free of the subreq before it's cleaned up by
> the parent req. Following convention we should then also do the same in
> smb2_ioctl_filesys_dup_extents_done().

You mean like in the convention of avoiding memory leaks? Yes! :)

> > Fix for that and an additional fixup attached.
>
> Looks good - please find one further patch attached, which I'll squash
> in if you're okay with it.

lgtm. Can you please send the final patchset so I can take a final look?

> > > > I don't see clone-range on the wire, trace attached. Am I missing something?  
> > >
> > > Interesting, thanks for checking this. I've been using the cifs.ko
> > > client until now.  
> >
> > ah, ok. Which kernel version do I need? I have 4.10.13-200.fc25.x86_64
>
> It went in with 02b1666544c08e245cb4e2253ed575f8128943d6, which was
> first carried in 4.2, so cp --reflink should trigger it on your system.

ah, great. Thanks!

-slow

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Mon, 8 May 2017 16:29:30 +0200, Ralph Böhme wrote:

> On Mon, May 08, 2017 at 04:01:16PM +0200, David Disseldorp wrote:
> > On Mon, 8 May 2017 11:05:38 +0200, Ralph Böhme wrote:
> >  
> > > On Mon, May 08, 2017 at 02:22:11AM +0200, David Disseldorp wrote:  
> > > > Thanks a lot for the review, Ralph!
> > > >
> > > > Please find a version 2 patchset attached. Further comments below...    
> > >
> > > better, but now it has a memory leak. :)  
> >
> > Ah, I take it you mean the free of the subreq before it's cleaned up by
> > the parent req. Following convention we should then also do the same in
> > smb2_ioctl_filesys_dup_extents_done().  
>
> You mean like in the convention of avoiding memory leaks? Yes! :)
It's a talloc child of the parent ioctl request, so will be freed with
that. Still worth fixing though :)

> > > Fix for that and an additional fixup attached.  
> >
> > Looks good - please find one further patch attached, which I'll squash
> > in if you're okay with it.  
>
> lgtm. Can you please send the final patchset so I can take a final look?

See attached. Your sign-off is on all except 04/10.

Cheers, David

dup_extents_xp2017_v3.patchset (58K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Changing a commit after sign-off from someone else (was Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE)

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Mon, 8 May 2017 11:05:38 +0200, Ralph Böhme via samba-technical wrote:

> > For the kernel this is a pretty common way of flagging changes which
> > have been made after an author (aaptel) has added his sign off:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n466
> > If Aurélien says that he's fine with the change as it is now, then I'll
> > drop the line completely.  
>
> yup. But afaict for us the signed-off tag already implies the person worked on
> the patch and they all jointly agree that the state of the patch is ok. So I
> don't really see a need for this extra flag.

I dropped the message here, but IMO such a message is courteous if you
make a change to a commit after the author has already signed off, for
the reasons given in the kernel guide:
"...it is very impolite to change one submitter's code and make him
 endorse your bugs" :-)

Cheers, David

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Mon, May 08, 2017 at 05:37:14PM +0200, David Disseldorp wrote:
> See attached. Your sign-off is on all except 04/10.

lgtm&pushed. Thanks!

-slow

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
Hi

It's been around a year since I last looked at this but it seems we are
changing the VFS API here (adding a flag param to the copy chunk vfs
function) shouldn't the version be bumped?

I've attended Jeremy's VFS talk last week at SambaXP and he mentionned
we should be careful about changing that API and generally avoid
breaking things, similar to the kernel.

I hate to be this guy but I think this might be better as a new
VFS function.

--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Wed, 10 May 2017 12:20:21 +0200, Aurélien Aptel via samba-technical wrote:

> It's been around a year since I last looked at this but it seems we are
> changing the VFS API here (adding a flag param to the copy chunk vfs
> function) shouldn't the version be bumped?

The VFS API was bumped from 36 to 37 for 306783d6f5d5 since the last
(4.6) release, so a further bump without any releases in between is
unnecessary IMO.

> I've attended Jeremy's VFS talk last week at SambaXP and he mentionned
> we should be careful about changing that API and generally avoid
> breaking things, similar to the kernel.

There are no VFS API stability grantees, it's best-effort. 306783d6f5d5
already makes API 37 significantly different to the previous version,
so I'd prefer to keep the new flags parameter.

Cheers, David

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Wed, May 10, 2017 at 01:02:19PM +0200, David Disseldorp wrote:
> On Wed, 10 May 2017 12:20:21 +0200, Aurélien Aptel via samba-technical wrote:
>
> > It's been around a year since I last looked at this but it seems we are
> > changing the VFS API here (adding a flag param to the copy chunk vfs
> > function) shouldn't the version be bumped?
>
> The VFS API was bumped from 36 to 37 for 306783d6f5d5 since the last
> (4.6) release, so a further bump without any releases in between is
> unnecessary IMO.

yup.

> > I've attended Jeremy's VFS talk last week at SambaXP and he mentionned
> > we should be careful about changing that API and generally avoid
> > breaking things, similar to the kernel.
>
> There are no VFS API stability grantees, it's best-effort. 306783d6f5d5
> already makes API 37 significantly different to the previous version,
> so I'd prefer to keep the new flags parameter.

we guarantee to keep it unmodified within a x.y release, but going from x.y to
x.y+1 can change it.

-slow

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Wed, 10 May 2017 13:20:31 +0200, Ralph Böhme via samba-technical wrote:

> > There are no VFS API stability grantees, it's best-effort. 306783d6f5d5
> > already makes API 37 significantly different to the previous version,
> > so I'd prefer to keep the new flags parameter.  
>
> we guarantee to keep it unmodified within a x.y release, but going from x.y to
> x.y+1 can change it.

Okay, I wasn't aware. If that is the case, then it's probably something
that we should put in README.Coding.

Cheers, David

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Wed, May 10, 2017 at 01:35:36PM +0200, David Disseldorp via samba-technical wrote:

> On Wed, 10 May 2017 13:20:31 +0200, Ralph Böhme via samba-technical wrote:
>
> > > There are no VFS API stability grantees, it's best-effort. 306783d6f5d5
> > > already makes API 37 significantly different to the previous version,
> > > so I'd prefer to keep the new flags parameter.  
> >
> > we guarantee to keep it unmodified within a x.y release, but going from x.y to
> > x.y+1 can change it.
>
> Okay, I wasn't aware. If that is the case, then it's probably something
> that we should put in README.Coding.

Yep, sorry. This is one of those "I thought everyone knew" things :-).

We must keep ABI stability within a x.y release, to keep third party
VFS modules working - moving to x.y+1 is when we can change.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Wed, May 10, 2017 at 12:20:21PM +0200, Aurélien Aptel via samba-technical wrote:
> I've attended Jeremy's VFS talk last week at SambaXP and he mentionned
> we should be careful about changing that API and generally avoid
> breaking things, similar to the kernel.

In the kernel we break our APIs all the time, and that's a good thing.
We certainly never bump version numbers when changing VFS interfaces.

That being said I know Samba does it differently although I disagree
with the reason.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Thu, May 04, 2017 at 08:58:10AM -0700, Christoph Hellwig wrote:

> On Thu, May 04, 2017 at 05:54:41PM +0200, David Disseldorp wrote:
> > On Thu, 4 May 2017 08:40:00 -0700, Christoph Hellwig wrote:
> >
> > > Not directly related to the patch, but IOC_CLONE_RANGE is a core
> > > VFS feature in Linux these days and for example support by XFS and NFS
> > > as well.  It's somewhat odd to have it in a vfs_btrfs module.
> >
> > Yeah, this'll hopefully get moved out of vfs_btrfs soon. A WIP
> > syscall(SYS_copy_file_range) patch from Björn is available at:
> > https://lists.samba.org/archive/samba-technical/2017-January/118259.html
>
> Don't use copy_file_range if you want to clone.  IOC_CLONE_RANGE is
> always the better choice if supported.

As I haven't seen any follow up here:  Can we please move the
IOC_CLONE_RANGE support out of the btrfs module as it's a general Linux
API, and can't just be replace with copy_file_range?

Reply | Threaded
Open this post in threaded view
|

Re: [PATCHSET] support FSCTL_DUPLICATE_EXTENTS_TO_FILE

Samba - samba-technical mailing list
On Thu, 11 May 2017 00:25:02 -0700, Christoph Hellwig wrote:

> > Don't use copy_file_range if you want to clone.  IOC_CLONE_RANGE is
> > always the better choice if supported.  
>
> As I haven't seen any follow up here:  Can we please move the
> IOC_CLONE_RANGE support out of the btrfs module as it's a general Linux
> API, and can't just be replace with copy_file_range?

I've raised https://bugzilla.samba.org/show_bug.cgi?id=12785 to track
this.

Cheers, David

12