On Tue, Jan 5, 2021 at 9:03 AM Ludwig Nussel
Hi,
While working on MicroOS, UsrMerge, UsrEtc, playing with systemd features I was wondering where that could lead us to. I'm sure we didn't utilize the full potential of what we can do with our OS yet. So I've tried to dump my thoughts into an article: https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslay...
tl;dr rpms to only operate below /usr and nowhere else.
This is very cool and quite similar to what I've been thinking about the past few months, especially since Fedora has moved to Btrfs by default on the desktop. - same realization that effectively the sysroot, the thing that's mounted and needed first is /etc/ because that's where fstab is and that's needed to assemble the rest of the system. And a light weight system reset [1] being essentially reverting to some default or empty /etc/ and /var/. - I've also found /usr/ on a read-only subvolume or snapshot is not too difficult although it is tied to the state of /var/lib/rpm/ right now. If everything is sourced in /usr/ then it's less controversial, if it ever was, to move the rpm database into /usr/. - I'm liking coreos/bootupd as a possible way to populate /boot and /boot/efi using /usr as a source. - I like even more not persistently mounting /boot/efi, which I consider unfortunate from day 1. And for all the same reasons /boot doesn't need to be persistently mounted either. These are bootloader and boot related things, and they should have proper owners, e.g. bootupd and fwupd, and those things should be able to mount them on demand, update them, unmount them. -But I still wonder whether there's a better, simpler, more flexible way to discover and assemble possibly different versions of /usr/ /etc/ and /var/ - and yes /home/ but I'll set that aside entirely because that discussion also should include systemd-homed. - And I wonder about piles of snapshots in hidden .snapshot directories, which ends up confusing the results from common tools like find, du, locate, and it'll even confuse many backup utilities where they'll really think you have 50x 50G worth of sysroot snapshots, or whatever. And that leads to whether various snapshotting utilities should have their own namespace for snapshots outside of the usual mount path. - And for that matter I wonder if each distro should have its own namespace so different versions of the distro, not just different updated states, can all coexist on Btrfs. + What could possibly bind the prior three, some variant of the systemd.io Discoverable Partitions Spec [3], but for subvolumes/snapshots (and readily adaptable for LVM thinp or ZFS databases, and so on). Is this useful? A way to name the top-level, generally invisible to the user, subvolumes and snapshots in such a way as to be self-describing, and obviate such dependency on fstab? Make fstab an addendum rather than primary and mandatory, in particular that it could be reset and we still want to boot. This now qualifies as ancient times. http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Specifically I'm looking at the "What We Propose" section, but even Lennart says it's stale and needs to be reimagined. But conceptually is it useful to have a way to bring some structure to subvolumes/snapshots, so they're out of the user's way? And also out of each other's way because there can be more than one reason for doing automated snapshots. libbtrfsutil offers a path based and file descriptor based means of creating snapshots. I don't know if that means persistently mounting the top-level e.g. somewhere in /run or if it's possible to forgo it using the _fd variant. I'm not opposed to nested subvolumes. A hybrid approach does seem to be indicated. But mainly to decomplicate fstab, discover and assemble at boot, and it seems attractive to compartmentalize, organize, have structure. -- Chris Murphy [1] A more serious, true reset that could recover from significant disaster even including unrepairable file system, based on btrfs seed, I think is less interesting by itself and more interesting if the effort can be used for other things like live images and/or install images. The replication feature is quite fast. And checksumming this source on every read means the result has integrity (making certain assumptions for brevity). [2] http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html [3] https://systemd.io/DISCOVERABLE_PARTITIONS/