Martin Wilck wrote:
On Tue, 2021-01-05 at 17:03 +0100, Ludwig Nussel
While working on MicroOS, UsrMerge, UsrEtc,
playing with systemd
features I was wondering where that could lead us to. I'm sure we
utilize the full potential of what we can do with our OS yet. So I've
tried to dump my thoughts into an article:
1. Rather than merging / and /etc, why not use tmpfs for / proper
(merge it with /run, for example), and mount /etc separately?
That would be also a possible model. systemd-nspawn does that for
volatile containers. With / on tmpfs what would be the meaning of the
kernel's root= parameter then though?
2. Why no CoW for data in general?
That's a good question. Is it safe to assume that services like libvirt,
postgres etc behave properly when their data is on a CoW fs?
Generally speaking, I like your proposal. It is
focused on the
principles of hierarchy simplification, snapshotting, and distribution
maintenance. Of course, as you have the distro maintainer hat on :-)
I believe there are other possible guiding principles for designing the
hierarchy, which should be taken into account when we redesign it. Here
comes a brain dump.
- NFS root or similar concepts, where system files
are shared between
multiple hosts. Is this obsolete today, as storage has become so cheap
that sharing system directories is no issue any more?
When the OS is read-only in /usr and data is clearly separated, sharing
should become easier than ever I hope. It really doesn't matter where
/usr comes from or how it's updated. The initrd just needs to be able to
- arch dependence / independence (think /usr/share
vs. /usr/lib). (If
we redesign the file system, we might consider stashing arch-dependent
files into separate hierachies, going from "lib vs lib64" towards
something like "lib.x86_64 vs lib.ppc64le" etc)
Personally I don't like lib64 but it's not in the way either as long as
we don't have to ship systems that run more than its 32 and 64bit
variants. To support two completely different architectures in one
volume, the /usr trees could be stored in separate partitions or btrfs
subvolumes. The discoverable partitions spec prepares for that already.
- package origin; the /opt vs. /usr topic has been
discussed on this
thread already. IMO it actually makes sense to store distro-provided
and 3rd-party-provided packages in separate file systems (*). But then,
if rpm was strictly confined to /usr, we'd either need a separate rpm
data base for 3rd party software, or fully switch to "foreign"
packaging such as appimage for 3rd parties ...
- ... which leads me to the question how these
foreign packages would
end up in your scheme. Do you consider them "data"? Would it make sense
to reserve a slot in the hierarchy for them?
Containers end up in /var and nobody questioned that so far :-) Where
are snaps and flatpaks stored? Also /var or ~ I assume. IMO 3rd party
packages are of the same kind.
- data with special needs such as VM images (no CoW)
images (docker storage). Ok, it's "data", but definitely with different
requirements than most other data.
- backup strategy. I like this a lot about your scheme; /usr would
essentially need no backup at all, as it could be easily recreated from
distro packages any time. But /home and /var also require different
backup strategies. Being able to use the same backup strategy for an
entire file system is a good thing in daily administration.
Yes, as I wrote elsewhere that needs a closer look too. There's at least
primary and secondary data where the latter does not need to be backed up.
- privacy and encryption. with per-user encrypted
$HOME, it makes
sense to store other data belonging to the users in the same file
system, like their mail spool or temporary files. World-writable /tmp
should be obsolete; basically nothing except the user's own $HOME
should be writable by the user. Data shared between users would live in
special, separate area. Similar considerations would hold for services.
The most simple solution to avoid thinking too much about that was full
disc encryption so far :-) It's a bit brute force but makes sure there
are no accidental leaks.
- user's personal files may have different
requirements as well. Some
are precious, some temporary, and many on a middle ground; some are
privacy-sensitive but most are not. I for one tend to do all my open-
source related work (i.e. all my work) outside of my encrypted $HOME.
I guess most of the stuff I mentioned is probably "data" in your scheme
and thus out of scope for your document. But the bottom line is that
there are lots of different types of "data", and I'm unsure whether
putting it all in a single top directory is really a good idea.
It probably isn't in a specific case indeed :-) The question is
basically whether a single volume for data is just good enough most of
the time so we can do that by default.
(o_ Ludwig Nussel
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)