Re: any idea about auto export multiple btrfs snapshots?

NeilBrown
2021-06-23T23:29:10Z

On Thu, 24 Jun 2021, J. Bruce Fields wrote:
> On Thu, Jun 24, 2021 at 08:04:57AM +1000, NeilBrown wrote:
> > On Thu, 24 Jun 2021, J. Bruce Fields wrote:
>
> One other thing I'm not sure about: how do cold cache lookups of
> filehandles for (possibly not-yet-mounted) subvolumes work?

Ahhhh... that's a good point. Filehandle lookup depends on the target
filesystem being mounted. NFS exporting filesystems which are
auto-mounted on demand would be ... interesting.

That argues in favour of nfsd treating a btrfs filesystem as a single
filesystem and gaining some knowledge about different subvolumes within
a filesystem.

This has implications for NFS re-export. If a filehandle is received
for an NFS filesystem that needs to be automounted, I expect it would
fail.

Or do we want to introduce a third level in the filehandle: filesystem,
subvol, inode. So just the "filesystem" is used to look things up in
/proc/mounts, but "filesystem+subvol" is used to determine the fsid.

Maybe another way to state this is that the filesystem could identify a
number of bytes from the fs-local part of the filehandle that should be
mixed in to the fsid. That might be a reasonably clean interface.

>
> > All we really need is:
> > 1/ someone to write the code
> > 2/ someone to review the code
> > 3/ someone to accept the code
>
> Hah. Still, the special exceptions for btrfs seem to be accumulating.
> I wonder if that's happening outside nfs as well.

I have some colleagues who work on btrfs and based on my occasional
discussions, I think that: yes, btrfs is a bit "special". There are a
number of corner-cases where it doesn't quite behave how one would hope.
This is probably inevitable given they way it is pushing the boundaries
of functionality. It can be a challenge to determine if that "hope" is
actually reasonable, and to figure out a good solution that meets the
need cleanly without imposing performance burdens elsewhere.

NeilBrown