On Oct 15, 2013, at 8:50 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Mon, 14 Oct 2013 14:20:14 -0600 > Chris Murphy <li...@colorremedies.com> пишет: > >> >>> Is there a way to detect that mountinfo gives garbage and somehow get >>> where the real root points? >> >> I don't know. I've asked on linux-btrfs@. Instead of rebooting, I merely >> tried mounting without options after changing the default subvolume to a >> nested subvolume (one attempt subvolume in a subvolume, another a subvolume >> in a directory): in both cases /proc/self/mountinfo reports / as the root, >> not the full path or ID of the subvolume actually mounted. >> >> Somehow it seems like the mountinfo root field should return a block device >> and full path to the mounted subvolume or its ID. Currently it seems like a >> problem. >> > > To quote one of btrfs developer (I had unrelated discussion on openSUSE > list): > > --><-- > This is a known problem, on my todo list, with a few non-working > solutions. > > If you mount via subvol=/subvol then /proc/self/mountinfo will show > 'subvol' as the mounted subvolume (4th column) > > 4 19 0:17 /subvol /mnt/ rw,relatime - btrfs /dev/sda15 rw,space_cache > > but if the subvolume is set-default and then implicitly mounted, > mountinfo will not show that (that's the bug). If mounted with subvolid= the same thing happens. Mountinfo doesn't show the subvolume name, it's just /. It's also a problem understanding from mountinfo all of the devices that make up a btrfs volume. This can be learned from btrfsprogs. > --><-- > > That said, information can be obtained also using different means > (btrfs utility or directly btrfs IOCTL). The question is to which > extent we want to depend on existence of btrfsprogs. Yeah at the moment if I use subvolid= to mount, I then have no idea how to find out what subvolume is mounted. As far as I know btrfsprogs doesn't a way to determine what subvols are mounted. It must be inferred (by mountpoint or by contents of the mountpoint). Anyway, as for support for subvolid in GRUB, I still think it would be nice as it's shorter than full paths. But this is not an enhancement hill I'm willing to die on by any means. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
