24 Feb
2021
24 Feb
'21
12:28 a.m.
On 2/23/21 10:29 AM, Greg A. Woods wrote:
Maybe there isn't any impetus to _create_ a
separate /usr these days
of large software but even larger disks.
I'm undecided. Part of me likes the / (root) and /usr split. But
another part of me questions /if/ and (if so) /why/ it is (still) /needed/.
However I think there are at least two good reasons to
_maintain_
a separate /usr. At least for ostensibly POSIX and Unix compatible
systems, that is.
Does /usr actually /need/ to be a /separate/ file system? Or would a
wholesale link from /usr to / (root) suffice? Or perhaps a collection
of sym-links from /usr/<foo> to /<foo> suffice?
For one there's a huge amount of deeply embedded
lore, human
(finger and brain) memory, actual code, documentation, and widespread
practices that use this separation and rely on it, effectively making
it a requirement.
Are they relying on the /separation/ of separate file systems? Or are
they simply relying on wrote memory for the path? Ergo sym-links could
fulfill the perceived need?
As Steve mentions above there's also the concept
of knowing the
minimum requirements for bringing up a system capable of the most
basic tasks.
The pat response to this in the Linux community is "That's what the
initrd / initramfs is for!"
What that fails to take into account is if the system actually uses an
initrd / initramfs or not. Many of the systems I maintain do /not/ use
an initrd / initramfs. Thus the systems have /some/ actual /need/ to be
able to bring up a minimal system to repair file system problems. Even
if the so called problem is simply that the extent file system needs an
fsck with human interaction (time since last check and / or maximum
number of mounts).
If you do use an initrd / initramfs, then you can reasonably safely lump
everything* in the / (root) file system.
*/boot still tends to be it's own file system on Linux, mostly because
that's where the initrd / initramfs image live which contain drivers for
more fancy things (software RAID, LVM, ZFS, SAN, etc.) which are needed
to bring up / (root).
Of course there's likely going to be some
variance in what any
given person might define as "most basic tasks", but that's most a
separate issue.
Agreed.
However, I posit that "most basic tasks" be what is necessary to
transition from single user mode to multi-user mode. Including any and
all utilities required to fix file systems, work with logical volumes,
SAN, etc.
However I will give one example of why this might be a
good thing to
know and preserved: it is highly useful for those creating "embedded"
systems, or application specific systems. They can start with just the
minimal root filesystem, and then know exactly what they have to add
in order to meet their application's requirements precisely. (and the
reasons for doing that can be much wider than many might assume)
Please elaborate on what that has to do with the / (root) vs /usr split?
I feel like you're differentiating between a minimal install vs a
kitchen sink install. Which seems to me to be independent of how the
underlying file system(s) is (are) arranged.
Also the basic idea of having a root filesystem that
contains just
and only what's necessary for the system to boot and run, and putting
everything else that makes the system usable to users into /usr,
is also still a worthwhile concept even just on its own.
Many in the Linux community think this is the job of the initrd /
initramfs. I personally believe that this is the job of the / (root)
file system.
Aside: In the event that /usr is on the / (root) file system, then the
system should still be able to come up as if /usr didn't exist b/c it
had been renamed or was on a separate file system.
The maintenance of an illusion of a separate /usr can
of course be
easily done with a farm of symlinks, thus preserving any dependencies
in anyone's memory, documentation, or code.
Agreed. With things like bind mounts, we don't even need to use
sym-links. }:-)
Though, one potential danger is that people see duplication between
/bin/<foo> and /usr/bin/<foo> and decide to remove one of them. Doing
so will ultimately remove both and cause someone to have a not good day.
Aside: Perhaps these not good days are not something to be avoided, but
instead something to be treated as a learning opportunity. Much like
young kids need to learn that fire is hot for themselves.
However the reality of maintaining a separate minimal
toolset for
system bring-up is that it cannot be reliably done without constant
and pervasive testing; and the very best (and perhaps only) way to
achieve this, especially in any smaller open-source project, is for
everyone to use it that way as much of the time as possible. I say
this from decades long experience of slowly moving systems to having
just one partition for both root and /usr and then on occasion testing
with separate root and /usr, and every time I do this testing I find
dependencies have crept in on something in /usr for basic booting.
(and that's even when I base my system on a platform that still tries
hard to maintain this separation of root and /usr!)
I have a different conundrum regarding */bin. Why do I need nine
different (s)bin directories in my path? I -- possibly naively --
believe that we have the technology to have all commands in /one/
directory, namely /bin.
Quickly after that thought, I realize that I want different things in my
path than other people do. So I end up with custom /bin directories.
Which usually ends up with sym-links that reference variables or custom
mounts (possibly via auto-mount applying some logic).
BTW, I think it was Sun that first did some of this
merging of root
and /usr a very long time ago.
Agreed. Though I'm far from authoritative.
--
Grant. . . .
unix || die