On Wed, Dec 12, 2018 at 06:05:57PM +0000, [email protected] wrote: > From: Filipe Manana <[email protected]> > > There is no reason why this check was performed for clone operations but > not for deduplication operations, after all deduplication is a special > case of cloning. So make the check happen for deduplication as well. > > This check used to be done and got removed by accident in commit > 2b3909f8a7fe9 ("btrfs: use new dedupe data function pointer"). > > Fixes: 2b3909f8a7fe9 ("btrfs: use new dedupe data function pointer"). > Signed-off-by: Filipe Manana <[email protected]> > --- > fs/btrfs/ioctl.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index 1e90d10b5638..ffe940ceb80a 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -3912,12 +3912,12 @@ static int btrfs_remap_file_range_prep(struct file > *file_in, loff_t pos_in, > > if (btrfs_root_readonly(root_out)) > return -EROFS; > - > - if (file_in->f_path.mnt != file_out->f_path.mnt || > - inode_in->i_sb != inode_out->i_sb) > - return -EXDEV; > } > > + if (file_in->f_path.mnt != file_out->f_path.mnt || > + inode_in->i_sb != inode_out->i_sb) > + return -EXDEV;
I'm checking if this is or is not a change in the dedupe behaviour regarding dedupe on different mont points. I can't see the f_path.mnt check anywhere in the VFS calls so after that patch deduping stops to work in some cases.
