Date: Thu, 30 Jan 2020 21:12:43 +0100
From: Joerg Sonnenberger <jo...@bec.de>
Message-ID: <20200130201243.gb90...@bec.de>
| Size constraints for root (and not the rest) seems a bit strange.
A result of technology changes, but ...
| That's more an argument for having a /boot filesystem
Yes, in a way it is, and if we properly supported that everywhere
this one wouldn't be an issue at all. [As an aside, the problem I
had with FreeBSD's required root size could not have been solved that
way, as the issue was the kernel modules - and in that case, debug
versions of them (which were large) - which were being unpacked into
where they'd need to be available during boot - all attempts to install
FreeBSD failed during the unpack (space ran out), it never reached the
state where anything bootable existed in the filesystem. Not relevant
for us, fortunately.]
As (I think) I said, while size issues might once have been the reason
for the split, they're not really (normally) what matters any more.
| Both would make sensible features for sysinst.
That's a step further than we need right now - an implementation
detail (or user convenience) - if we can make things work properly,
and a modified scheme turns out to be useful, and desired, then we
can worry about making it easy for users to set up. Until then,
more "you probably don't want this" options in sysinst just make
it more confusing - so we should forget that issue until the real
problems are solved ... and not just fall back on "well, sysinst
can't do it yet, but if it could ..." as an excuse.
| I'm not sure what filesystem attributes you want to apply to /
| that don't also apply to /usr just as well.
Aside from readonly, which you comment on below (and I will return to
there) there's also the block'frag sizes, nodev (which a proper devfs might
allow to be applied to / but we're dicussing what can be done to solve
a current issue, not a pipe dream for the distant future). There's also
the issue of placement - optimal use of resources. / (incl /bin and /lib)
contains a lot of data that is used frequently - if RAM is big enough to
cache it all, and there's no better use for that RAM, then great - otherwise
it is useful to have / on a fast access device (like an SSD). On the other
hand /usr is contains lots of stuff that we need to have available (and I'm
sure, some we don't, but let's forget that issue for now) but which gets
accessed very rarely, and where access speed doesn't really matter, so
rotating devices work just fine.
| I can understand making it readonly, but why exclude root from that?
That would indeed be nice, but...
| Being able to mount /etc is only slightly more tricky to bootstrap.
Slightly?
Wherever we specify from where /etc is to be mounted (which obviously would
not be able to be /etc/fstab) is a configuration file, and needs to be
writable, and hence on a writable filesystem. Keeping /usr as a separate
filesystem is a much easier task. It has been done, for varying reasons,
for decades and making it read only "just works" if its subdirs that want
to be written are also separate filesystems - /usr/pkg /usr/src /usr/obj
(or renamed).
In case it isn't clear, I *like* lots of separate filesystems. One of
my systems has 60 lines in /etc/fstab (of which just 3 are comments, and
I think only 1 or 2 represent removable media (/cd type things)). They're
not all mounted, there are a lot of "noauto" flags in there, they come and
go as needed (both in the sense of being mounted, and of existing at all).
kre
