On Mon, Jul 13, 2020 at 4:12 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Fr, 10.07.20 18:55, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > > > There's really no need to complicate things by pushing btrfsisms into > > > user-visible concepts needlessly. > > > > It's been this way in Fedora for a decade. > > Well, that's an argument one could also use against btrfs. We are > trying to improve things here, hence arguing with "this has always > been that way" is not leading anywhere... 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. > > When I say understandable, I mean a user can follow a trail of > > breadcrumbs for boot, startup, and assembly: not just rootflags, but > > also that systemd at sysroot mount time, also uses the 'subvol=' mount > > option. Whereas if this is a leap, they can't follow it. > > 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? > > > 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. Whatever is the thing that sets rootflags parameter also sets the root parameter; and this thing would necessarily need to learn how to get/set the default subvolume instead. This is not a mkfs time option. The target subvolume for the installation doesn't exist yet at mkfs. > 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. 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. >not just at boot, but also in systemd-nspawn > when you point it to such an image, and various other systemd tools. I > am pretty sure it would be reall nice if btrfs would be set up the > same way: entirely self descriptive, so that the mount hierarchry is > determined from itself, without needing an external config source such > as the kernel cmdline or fstab. It would be nice. -- Chris Murphy _______________________________________________ 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
