On Mon, Oct 22, 2018 at 10:35 PM Olga Kornievskaia <olga.kornievskaia@xxxxxxxxx> wrote: > > On Mon, Oct 22, 2018 at 3:06 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Mon, Oct 22, 2018 at 02:45:04PM -0400, Olga Kornievskaia wrote: > > > On Sat, Oct 20, 2018 at 4:54 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > Another thing is the commit message claims to: > > > > "Allow copy_file_range to copy between different superblocks but only > > > > of the same file system types" > > > > > > > > But what the patch actually does is: > > > > "Allow copy_file_range() syscall to copy between different filesystems > > > > AND allow calling the filesystems' copy_file_range() method > > > > between different superblocks but only of the same file system types" > > > > > > > > It's probably OK and quite useful to do the former, but maybe man page > > > > should be fixed to explicitly mention that the copy is expected to work > > > > across filesystems since kernel version XXX (?) > > > > > > > > If you don't wish to change cross filesystem type behavior and only > > > > relax cross super block limitation, then you should replace the > > > > same inode->i_sb check above with same inode->i_sb->s_type > > > > check instead of doing the check only for calling the filesystem > > > > copy_file_range() method. > > > > > > Thank you for the feedback. In the next version, I will remove the > > > check for the functions and instead check for the same file system > > > types. > > > > Jeff and I agree that this is the wrong way to go. Instead, the > > cross-device check should be in the individual instances, not the top > > level code. > > So remove the check all together for the VFS (that was my original > patch to begin with (like #1 not this one). So am I missing the point > again, I keep getting different corrections every time. Because there are different opinions... although you did get the opinion of the VFS maintainer, which was: compare i_sb->s_type. Jeff, Matthew, really, what's the use of "allowing" cross fs type copy inside filesystem code? and which method is going to be called? file_out->f_op->copy_file_range()? file_in->f_op->copy_file_range()? Do we need to check if both are implemented? either? This is just confusing Olga and gives no real value to anyone. If we ever have a filesystem copy_file_range() method that can deal with cross fs type copy, we can change it then when we know the required semantics of that future call. That is not to say that we cannot relax same fs type from copy_file_range() syscall. That has already been done with the current patch, just not officially declared in commit message. Thanks, Amir.
