why check f_path.mnt is equal for source and dest in btrfs_ioctl_clone()?

This gives EXDEV for clone operations that btrfs could otherwise execute and with slight change of circumstances will actually execute fine.

Imagine we have a btrfs on /dev/mapper/foobar with subvols /foo and /bar. Let’s also imagine top of said fs in mounted at /mnt. In this case, a cross-subvol clone of /mnt/foo/srcfile to /mnt/bar/dstfile will succeed.

However, if only the individual subvols were mounted like this:
/dev/mapper/foobar on /mnt (subvol=foo)
/dev/mapper/foobar on /mnt2 (subvol=bar),
then a clone of /mnt/srcfile to /mnt2/dstfile will fail with EXDEV even though it is otherwise equal to the former clone operation.

Would anyone care to shed some light on this? Is it due to legacy policy? Am I missing something?

Thanks
–Stefan

This does not cross a mountpoint.

And this does. This is prevented for the same reason hadlinks do not work accross mountpoints when the same filesytem is mounted multiple times.

http://thread.gmane.org/gmane.comp.file-systems.btrfs/9867

Although it's more about reflink/clone spanning subvolumes regardless of the mountpoints, there's an objection against file operations performed accross vfsmounts and current implementation respects that.

david