On Wed, Jun 12, 2019 at 3:58 AM David Sterba <dste...@suse.cz> wrote: > > On Tue, Jun 11, 2019 at 10:03:51PM -0600, Chris Murphy wrote:
> > There are a couple of things going on. One is something between VFS > > and Btrfs does this goofy assumption that bind mounts are subvolumes, > > which is definitely not true. I bring this up here: > > https://lore.kernel.org/linux-btrfs/CAJCQCtT=-YoFJgEo=bfqfipdtmojcyr3djpsekf+hq22gyg...@mail.gmail.com/ > > The subvolumes build on top of the bind mount API internally but it is > or should be a different kind of object. > > > Near as I can tell, Btrfs kernel code just needs to be smarter about > > distinguishing between bind mounts of directories versus the behind > > the scene bind mount used for subvolumes mounted using -o subvol= or > > -o subvolid= ; I don't think that's difficult. It's just someone needs > > to work through the logic and set aside the resources to do it. > > I tried to fix that and got half way through, then hit the difficult > problems mainly with nested subvolumes. For leaf subvolumes, the > difference between > > subvolume/dir/dir/dir (bind mounted) > > and > > subvolume (mounted with -o) > > is to traverse back the path until the subvolume is hit, which in both > cases would be 'subvolume'. Howvever, with nested subvolumes it's not > easy to see where to stop > > subvol1/dir/dir/subvol2/dir/dir/subvol3/dir/dir > > and take 3 cases: > > mount -o subvol=subvol1 > mount -o subvol=subvol2 > mount -o subvol=subvol3 > > the backward path traversal will always say it's subvol3 (that's wrong > from users POV). Keeping track of the exact subvolume that was mounted > is not trivial because it partially has to duplicate the internal VFS > information which makes it hard to keep consistent after moves. > > There was a concept proposal called 'fs view' that would add proper > subvolume abstraction for subvolumes to VFS but I don't know how far > this got. I guess I'm curious why in these cases the subvolid number is correct in mount and mountinfo, but the subvol name is wrong? And if it's not just anomalous that the id is correct, why not just use that and do a lookup of id to name instead of however the name is currently determined? -- Chris Murphy
