On Tue, Oct 23, 2018 at 6:39 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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.
