On Mo, 13.07.20 09:23, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > I offer it to contradict the assertion that the current arrangement is > "pushing btrfsisms". It is originally Fedora. And having to use btrfs > specific commands to set/get the default, as you propose, is the > "btrfsism" - in my opinion. > > Also, Btrfs in Fedora is not new, it's been discussed off and on over > these same 10 years. Yet this is the first criticism I've come across > for this use of rootflags. > > Since it's mostly bootloader domain, and relates to a snapshot and > rollback paradigm as well, I think it's properly addressed in design > and planning that feature. It's not just a boot loader thing. By requiring this to be specified explicitly, you make sure that "systemd-nspawn -i" and the various other tools cannot make sense of it automatically. Quite frankly, I don't see why the boot loader should care about the btrfs subvolume the initrd later picks at all.. > > I think a system that automatically discovers what it needs and works > > without configuration and everywhere the same is what we should strive > > for. Requiring configuration for this kind of stuff just makes stuff > > fragile... > > Is the root parameter fragile? Yes, because you have to propagate it everywhere, and if you omit it things break, since it's a secondary place you store information about the root disk in that you strictly need to have to be able to make sense of the file system. So yes, requiring a special parameter to be passed everywhere just sucks, as this magic info is needed on every boot and needs to be passed everywhere, i.e. to the boot loader for physical boots, to the brain of the hacker who wants to recover the fs if something goes wrong, to tools like systemd-nspawn (and the other tools systemd has that can take disk images) and so on. > > > If the user mounts this file system elsewhere, including from a > > > livecd, they actually won't see their home, it's hidden. How are they > > > supposed to know where it is or how to find it, without learning > > > btrfsisms? > > > > Booting is something you do every day, we want that safe and robust. > > And it is currently. I don't see how it's any more safe and robust by > eliminating only rootflags, but not the root parameter. You don't need the root parameter, actually. systemd automatically finds the root fs for you, it can do that if the root fs is properly advertised via the GPT partition type, according to the Discoverable Partition Spec. https://systemd.io/DISCOVERABLE_PARTITIONS So yes, it is an explicit goal to make things robust so that a kernel command line is not necessary for the default way things work, you only use it to deviate from the default. > > BTW, we once upon a time added a TODO list item of adding a btrfs > > generator to systemd, similar to the existing GPT generator: it would > > look at the subvolumes of the root btrfs fs, and then try to mount > > stuff it finds if it follows a certain naming scheme. This would make > > images entirely self-explanatory (i.e. you wouldn't have to know > > external info such as subvol=root is the root, and subvol=home is > > /home, and so on), but the file system would describe itself entirely, > > just by having things named in a certain way. Because right now for > > GPT we have this behaviour: if you use the GPT partition types of the > > "Discoverable Partition Spec", then we'll automatically discover and > > mount partitions for you, > > A variation on this is in discussion for a little bit now, perhaps > most recently here: > https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/2#note_865189 > > There is a difficulty. It is very easy to (externally) parse a GPT, > and look for a partition type GUID. It is not nearly as easy to > (externally) parse a Btrfs for subvolumes. The easiest way to get > access to all subvolumes is via kernel ioctl, but you need to mount > the file system for this. The other way is enhance the GRUB btrfs > driver to be able to look for subvolumes and read XATTR, basically use > it as a read-only parser to find what you're looking for and then > mount by subvol name or ID. Hm, grub? what? I am talking about mounting secondary subvolumes automatically, i.e. in the initrd or early on after the transition to the host OS. In systemd we have enough btrfs code anyway for managing subvols, writing a generator is trivial for us and would add very little new code. It's mostly an excercise in figuring out how to name things, and which subvols to cover. > Stuffing this information in an XATTR might be the easiest way to go > about it. I'm not sure whether the btrfs uuid tree could be used to > associate file btrees (subvolumes) with arbitrary partition type > GUIDs, or whether there's an advantage of doing so versus the work > implied. xattrs? That sounds unnecessary. I think the easiest would be to just operate on subvoumes that are named a certain way. For example, we could say, if the generator finds a set of subvolumes called "/_home.<something>" on the root fs, then it would sort them by name, and pick the last one of it, and automatically synthesize a .mount unit that mounts it to /home. And similar for other relevant dirs. That way, if you want to opt into this simple logic, just name your subvols /_home.xyz and there you go. The suffix you can then use for versioning or so, if you like, but we wouldn't care in the generator how you actually make use of it. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
