DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5AFAB207DD
MIME-Version: 1.0
References: <20181019153018.32507-1-olga.kornievskaia@gmail.com>
 <20181019153018.32507-2-olga.kornievskaia@gmail.com> <20181020040530.GG32577@ZenIV.linux.org.uk>
 <CAOQ4uxhAvypEvGap02CkH_bHtFt7tUVxTWeZUL5OV_V8xwWjDA@mail.gmail.com>
 <CAN-5tyHqtV7YhfK7DY4rY643bbfV=8MOE6=mxHYJufCsdcN9Jw@mail.gmail.com>
 <20181022190620.GA8863@bombadil.infradead.org> <CAN-5tyF=voE2=DBLKvJCHZc9+zMzysqD8REYYb-z5jwq2BLqGQ@mail.gmail.com>
 <a4a3ac1e840444871f3bc87606b111668c66618b.camel@redhat.com>
 <CAOQ4uxiRnyxtOXBrdCvUcTa8GkTb2OyaJYJ58Ddoik0=3Y9pyA@mail.gmail.com>
 <CAN-5tyHQc3M2YprFJm35XUxJdAx11a85o1NygE5FQFyHq3SQew@mail.gmail.com> <20181023153941.GE20085@bombadil.infradead.org>
In-Reply-To: <20181023153941.GE20085@bombadil.infradead.org>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Wed, 24 Oct 2018 14:32:58 +0300
Message-ID: <CAOQ4uxj88JqhO0GF3Sim1kETPCBkZCVeAqGzWKVyCXkDwBLriw@mail.gmail.com>
Subject: Re: [PATCH v1 02/11] VFS permit cross device vfs_copy_file_range
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Olga Kornievskaia <olga.kornievskaia@gmail.com>,
        Jeff Layton <jlayton@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        fweimer@redhat.com, Steve French <smfrench@gmail.com>,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        Christoph Hellwig <hch@lst.de>, linux-api@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Tue, Oct 23, 2018 at 6:39 PM Matthew Wilcox <willy@infradead.org> wrote:
>
[...]
> I've done some more research and found that while NFSv4.2 has its own
> representation of a copyable range of a file, iSCSI and SMB3 share the
> same ROD.  So it's not at all implausible that some other filesystem
> might also decide to use the same ROD, perhaps even NFS v4.3.
>
> It's clearly crazy to expect filesystem A to know about all the
> interpretations of filesystem B's file->private.  I'd expect us to add
> a function like:
>
> int vfs_get_rod(struct file *src, struct file_rod *rod);
>
> and then a filesystem's copy_file_range() would check to see if both
> src and dest referred to the same server, and if not call vfs_get_rod()
> to be able to send the ROD to the destination.
>

I am not saying cross filesystem type copy won't be possible.
I'm just saying we are going to get the API wrong anyway.
Surely, it is going to be either cifs or nfs42 that supports cross
fs copy first, not both at the same development cycle, so now
it seems flaky to use the out_file's copy_file_range() method.
You'd want to figure out which of the in/out fs supports cross fs
copy and call that method (not enough information).
I suspect we will need a new cross_copy_file_range() method.

And to answer Olga's question, yes, I do find cross fs copy with
do_splice_direct() beneficial.

Thanks,
Amir.