On Oct 13, 2013, at 11:28 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Sun, 13 Oct 2013 17:58:41 -0600 > Chris Murphy <li...@colorremedies.com> пишет: > >> >> On Oct 13, 2013, at 5:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko >> <phco...@gmail.com> wrote: >> >>> On 13.10.2013 22:59, Chris Murphy wrote: >>>> >>>> How does one create a subvolume without a name? All subvolumes have had >>>> ID's since at least 2008, and it's been possible to mount by name or ID >>>> for quite a few years at least as well. >>>> >>> Then this illusion was created by the /proc/mountinfo listing mounted >>> subdirectory as "/" when mounted by id (or something like that). >> >> The top level subvolume (id 5) is likely reported as "/" just like is the >> case when mounting any file system. >> >> It's possible that changing the default subvolume causes this same behavior >> rather than mount reporting the full path. I haven't tested this. >> > > No, it is inconsistent behavior for named subvolume and subvolume ids > mounts. > > For named subvolume btrfs internally mounts top level directory > (actually using subvolid=0 for this internal mount) and then performs > equivalent of bind mount on subvolume. For subvolid it actually > sets root of filesystem to subvolume during mount. As mountinfo > displays path relative to filesystem root, it is always "/" if subvolid > was used. I do not know if there are practical differences between the > two. I'm finding partial corroboration with this. Mounting subvolid= does not show either subvolume id or name, which seems like a problem. At the moment, I'm unable to confirm/deny that mountinfo correctly shows full path because when I change the default subvolume, I'm dropped to a grub rescue prompt on the next boot. This isn't expected because set reveals: prefix=(hd0,msdos1)/boot/grub2 root=jd0,msdos1 In fact, /boot is a subvolume under top level 5. So if GRUB is using full paths, which it seems to be, it should be able to still resolve this even though the default subvolume is not the top level 5 subvolume. Yet it's not working. So it seems that GRUB is using relative pathnames to the default subvolume. That's a problem also because it effectively means btrfs subvolume set-default can't be used without breaking bootability. > > Why full paths are cumbersome? The > > mount -o subvol=path/to/boot /dev/sdX /mnt > vi /mnt/grub/boot.cfg > > is 100% equivalent to > > mount -o subvolid=0 /dev/sdX /mnt > vi /mnt/path/to/boot/grub/boot.cfg It's not 100% equivalent in behavior. For one, paths can become quite long depending on the snapshotting strategy and complexity of the hierarchy. If that hierarchy ever changes, now the mount option must change and the grub.cfg must change or the system is unbootable. That's not the case with ids; the system remains bootable without having to modify fstab or grub.cfg. > > And GRUB is concerned only with value of $prefix. So as long as > grub-install can resolve path name of /boot/grub to full path from > btrfs root including subvolumes it is OK. I'm uncertain about this, because upon changing the default subvolume, I can't boot. Hence at least core.img appears to treat what looks like a full path, as relative to the default subvolume, whereas full paths should always be treated relative to top level 5 subvolume. > And to use subvolume ID you > will need to detect that path is on subvolume anyway. I don't know what this means. The file system clearly can resolve the location of a subvolume independent of path. > >> Today, maybe it's not the best scenario to have two or three OS's installed >> on one btrfs volume, in separate subvolumes, each with hundreds of >> snapshots. But it's designed to enable such a workflow once it's stable. I >> think using full paths (always relative to the top level subvolume which >> never changes even if the default subvolume is changed) is fine in the near >> term. And it may be some workflows simply prefer the (human user) >> transparency that comes with full paths. But from my perspective, a fixed >> number means I can completely reorganize a hierarchy with no other changes. >> > > Could you please provide example of what you mean here? If I use subvolid's everywhere, it means I could grab Fedora's default hierarchy: boot root home, which are subvolumes, and move them into a either a folder or subvolume called "Fedora 20" and upon reboot everything still works. Right now, that's not the case. If I move these things, or rename them, boot breaks. It's sortof like using volume labels or partition names to quality paths. There's a reason why UUID is preferred to labels, because if the user depends on labels, then relabels a volume, they can't boot. So there's a better way to do this that preserves the user's ability to name user domain things like volume labels, while not breaking system domain things like an immutable way of booting the system. It's about making bootability more robust. >>> The rename may very well be >>> intentional in order to make other OS and/or version to boot. >> >> Yes, and I'm not suggesting the end to supporting either full path, or >> relative path referencing of subvolumes. Just that it's also possible to use >> subvolid. >> > > What about grub-mkconfig? It does not pass explicit subvolume if it is > not present in mountinfo, which means a) if someone changes default > subvolume it will end up mounting wrong root and b) it breaks if mount > by subvolid is used. Clearly there are some things returned by mountinfo that need fixing and enhancement. The same can be said about the mount command. And tools like gnome-disk-utility need some things about _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
