On 6/23/21 5:04 PM, NeilBrown wrote:
On Thu, 24 Jun 2021, J. Bruce Fields wrote:
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.
I'm very confused about what you're talking about. Is this documented
somewhere? I mean, I do use autofs, but see that as a separate software
system working with NFS.
BTRFS
effective sees multiple volumes on the block device and could do the
same thing.
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.
All we really need is:
1/ someone to write the code
2/ someone to review the code
3/ someone to accept the code
How hard can it be :-)
NeilBrown
