On 2023/11/1 03:36, Christoph Hellwig wrote:
On Tue, Oct 31, 2023 at 01:50:46PM +0100, Christian Brauner wrote:
So this is effectively a request for:
btrfs subvolume create /mnt/subvol1
to create vfsmounts? IOW,
mkfs.btrfs /dev/sda
mount /dev/sda /mnt
btrfs subvolume create /mnt/subvol1
btrfs subvolume create /mnt/subvol2
would create two new vfsmounts that are exposed in /proc/<pid>/mountinfo
afterwards?
Yes.
That might be odd. Because these vfsmounts aren't really mounted, no?
Why aren't they?
So did you mean that, if we have a btrfs with two subvolumes under the
fs tree:
/subv1
/subv2
Then we mount the fs root, we should have subv1 and subv2 all showing up
at mountinfo?
Can we make this more dynamic? Like only initializing the vfsmount if
the subvolume tree got its first read?
And so you'd be showing potentially hundreds of mounts in
/proc/<pid>/mountinfo that you can't unmount?
Why would you not allow them to be unmounted?
This unmount may not make much sense, as:
- It break the assumption all subvolumes can be access from fs tree
- We may re-initialize the vfsmount every time we read that subvolume
But otherwise the vfsmount per-subvolume solution looks at least worthy
a try to me.
Thanks,
Qu
And even if you treat them as mounted what would unmounting mean?
The code in btrfs_lookup_dentry that does a hand crafted version
of the file system / subvolume crossing (the location.type !=
BTRFS_INODE_ITEM_KEY one) would not be executed.
