Chris Murphy wrote:
On Tue, Jan 5, 2021 at 9:03 AM Ludwig Nussel
wrote: 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.
I really hope they don't repeat all the mistakes SUSE made on the way :-)
- 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.
I agree.
[...] - 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.
Yeah, similarly to /boot I guess. Should be sufficient if snapper provides access when needed.
- 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.
Sure, certainly a nice gimmick for nerds that we may get for free when kept in mind. Not sure if it's of much practical relevance though :-)
+ 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.
Absolutely. Also, I'd like to think of revisions of a particular tree rather than snapshots. That probably changes the way to look at potential new naming schemes. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)