On Thu, Jun 24, 2021 at 08:04:57AM +1000, 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. 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.
