Fwd: [PATCH v1 2/3] VFS permit cross device vfs_copy_file_range

[Steve French]

Adding cifs/samba mailing list since this is probably of more interest
to those (SMB3 etc.) than for other file systems which don't as
broadly support the various types of copy offload mechanisms that
Samba etc. deal with


On Fri, Aug 31, 2018 at 11:41 AM Olga Kornievskaia <aglo at umich.edu> wrote:
>
> On Fri, Aug 31, 2018 at 12:14 PM Florian Weimer <fweimer at redhat.com> wrote:
> >
> > On 03/02/2017 05:02 PM, Olga Kornievskaia wrote:
> > > Allow nfs_copy_file_range to copy across devices.
> > > NFSv4.2 inter server to server copy always copies across devices, and
> > > NFSv4.2 intra server to server copy can copy across devices on the same
> > > server.
> > >
> > > If a file system's fileoperations copy_file_range operation prohibits
> > > cross-device copies, fall back to do_splice_direct. This is needed for
> > > nfsd_copy_file_range() which is called by the inter server to server
> > > destination server acting as an NFS client, and reading the file from
> > > the source server.
> > >
> > > Signed-off-by: Andy Adamson<andros at netapp.com>
> >
> > What has happened to the patch?  We unwittingly used copy_file_range in
> > the glibc test suite, without realizing that it does not support
> > cross-device copies.
>
> I'm still planning to fight for the patch to be included. As per
> maintainers request, I separated out the async copy patches out and
> hopefully that will be going into 4.20. I'm working on the "inter"
> copy offload functionality which does require this patch. I will start
> submitting and pushing this patch along with the rest of the patches.
>
> Are you interested in the copy_file_range() functionality that does
> support cross-device copies? If so can you tell me how are you using
> it? It would be also helpful to watch for the submission of the patch
> and argue in its favor.

SMB3 clients and server (Windows, Macs, Samba and probably most
every modern NAS out there) support the SMB3 "CopyChunk"
operation used by the Linux client.

I would expect that one of the most useful cases is cross device
For example you have two mounts to your server or server cluster
\\server\share1 is mounted to /mnt1
and
\\server\backup is mounted to /mnt2

and you want to do copy_file or copy_file_range of various
files from /mnt1 to /mnt2

As long as they are both the same file system type, why not
let the file system tell you whether it can do the copy.

Given that this is 10x to 100x faster than the alternative
and this is a common case (and there are many 100s of millions
of SMB3 server capable systems out there which already support
copychunk (and thus would support copy file) - why would we
want to restrict it.

It is much saner to let the file system tell the VFS if it can't
support the cross device copy.

---- and to make it even more obvious why this patch matters ---
Virtualization clients (and various Windows and NetApp server)
support another copy offload mechanism (not just CopyChunk)
ie via ODX which would support cross server not just cross share
copy.    Enabling this would be a BIG incentive for finishing up
ODX copy support in Linux (cifs.ko using SMB3).   This is
fairly widely supported by servers.




--
Thanks,

Steve


-- 
Thanks,

Steve