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

[David Sterba <dsterba@suse.cz>]

On Sun, Jun 30, 2013 at 09:55:26AM +0200, Stefan Paletta wrote:
> 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.

This does not cross a mountpoint.

> 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.

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

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

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