Re: [PATCH] fs: allow cross-vfsmount reflink/dedupe

["NeilBrown" <neilb@suse.de>]

On Tue, 22 Feb 2022, NeilBrown wrote:
> On Thu, 17 Feb 2022, Wang Yugui wrote:
> > Hi,
> > 
> > > On Thu, 17 Feb 2022, Wang Yugui wrote:
> > > > Hi,
> > > > Cc: NeilBrown
> > > > 
> > > > btrfs cross-vfsmount reflink works well now with these 2 patches.
> > > > 
> > > > [PATCH] fs: allow cross-vfsmount reflink/dedupe
> > > > [PATCH] btrfs: remove the cross file system checks from remap
> > > > 
> > > > But nfs over btrfs still fail to do cross-vfsmount reflink.
> > > > need some patch for nfs too?
> > > 
> > > NFS doesn't support reflinks at all, does it?
> > 
> > NFS support reflinks now.
> > 
> > # df -h /ssd
> > Filesystem              Type  Size  Used Avail Use% Mounted on
> > T640:/ssd               nfs4   17T  5.5T   12T  34% /ssd
> > # /bin/cp --reflink=always /ssd/1.txt /ssd/2.txt
> > # uname -a
> > Linux T7610 5.15.24-3.el7.x86_64 #1 SMP Thu Feb 17 12:13:25 CST 2022 x86_64 x86_64 x86_64 GNU/Linux
> > 
> 
> So it does ..... ahhh, the CLONE command in NFSv4.2.....
> This is used by the .remap_file_range file operation.  That operation
> only gets called when the "from" and "to" files have the same
> superblock.
> btrfs has an ....  interesting concept of filesystem identity.  While
> different "subvols" have the same superblock locally, when they are
> exported over NFS they appear to be different filesystems and so have
> different superblocks.  This is in part because btrfs cannot create
> properly unique inode numbers across the whole filesystem.
> Until btrfs sorts itself out, it will not be able to work with NFS
> properly.

Actually, that might be a little bit simplistic...

How are you exporting the btfs filesystem on the server.
If you are exporting each subvolume separately, then they probably look
like different filesystems to NFS.  If you export just the top level and
allow the subvolumes to be accessed by name, then they should have the
same superblock and reflink should work.

NeilBrown