Re: [TUHS] /usr separation

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 6096 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]