On Thu, Jun 24, 2021 at 08:04:57AM +1000, NeilBrown wrote:

On Thu, 24 Jun 2021, J. Bruce Fields wrote:

quoted

Is there any hope of solving this problem within btrfs?

It doesn't seem like it should have been that difficult for it to give
subvolumes separate superblocks and vfsmounts.

But this has come up before, and I think the answer may have been that
it's just too late to fix.

It is never too late to do the right thing!

Probably the best approach to fixing this completely on the btrfs side
would be to copy the auto-mount approach used in NFS.  NFS sees multiple
different volumes on the server and transparently creates new vfsmounts,
using the automount infrastructure to mount and unmount them.  BTRFS
effective sees multiple volumes on the block device and could do the
same thing.

Yes, that makes sense to me.

I can only think of one change to the user-space API (other than
/proc/mounts contents) that this would cause and I suspect it could be
resolved if needed.

Currently when you 'stat' the mountpoint of a btrfs subvol you see the
root of that subvol.  However when you 'stat' the mountpoint of an NFS
sub-filesystem (before any access below there) you see the mountpoint
(s_dev matches the parent).  This is how automounts are expected to work
and if btrfs were switched to use automounts for subvols, stating the
mountpoint would initially show the mountpoint, not the subvol root.

If this were seen to be a problem I doubt it would be hard to add
optional functionality to automount so that 'stat' triggers the mount.

One other thing I'm not sure about: how do cold cache lookups of
filehandles for (possibly not-yet-mounted) subvolumes work?

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.

--b.