On Sat, 28 Sep 2013 01:10:14 +0200, Alan McKinnon wrote about Re:
[gentoo-user] separate / and /usr to require initramfs 2013-11-01:

> On 28/09/2013 00:57, Dale wrote:
> > Bruce Hill wrote:
> >> On Fri, Sep 27, 2013 at 05:33:02PM -0500, Dale wrote:
> >>> I'm hoping that since I use eudev, I don't have to worry about
> >>> this. If I do, this could get interesting, again. Dale 
> >> Do you have /usr separate from / ?
> > 
> > Yep.  From my understanding tho, eudev is not supposed to be
> > affected by this problem tho. 
> > 
> > One reason for this being seperate, I have / and /boot on a regular
> > partition and everything else on LVM.  Sometimes that /usr gets a
> > bit full.  It's not so bad after I moved all the portage stuff out
> > and put it in /var.  Now I have to watch /var too.  lol 
> 
> 
> Ask yourself this question:
> 
> Why do you have /usr separate?
> 
> No really, *why exactly*?

You write as though you expected the question to be regarded as
rhetorical.

I can't speak for Dale, but since I have much the same arrangement
(with /boot and / on physical partitions and everything else under LVM2
control) I shall write from my perspective.

The reason I have /usr separate is so that I can have it striped
without needing an initramfs.

> One of the very first things you do with /usr at boot time is mount
> it, and from then on you use it exactly as if it were always on /
> anyway.

No.  The I/O characteristics of a striped /usr are rather different from
those of / on a simple partition.

> I'll bet that since you moved all of portage out, your mount
> options and fs configs are the same between the two anyway.

Again no.  My portage volume has different mount options from /usr, as
it has nosuid and noexec in force.  The portage volume is not striped
either, as it does not get as much I/O traffic as /usr.

> So what
> exactly does a separate /usr get you on a stabd-alone workstation buy
> you?

It buys me decent performance from elderly PATA hard drives.  Striping
gives a throughput multiplier on that corner of the DASD farm.

This is advantageous because /usr/bin and /usr/lib receive a lot of
data traffic running application programs -- much more than /bin
and /lib.  The /usr/bin directory appears earlier in my PATH than /bin
and the majority of application software is loaded without /bin being
troubled.  The faster the /usr LV can respond, the faster software can
load.

> I've been looking at this for ages and conclude it buys me
> nothing but pain. They don't even change much if /home and /var are
> elsewhere, so guage your size right (easy to do) and never need look
> at it again.
> 
> Separate /usr for the most part is an ancient artifact from decades
> ago. It's useful in edge cases but not in the general case with modern
> hardware. So why do people do it? I reckon it's inertia and nothign
> more. Which is kinda silly as inertia ignores everythign else in the
> environment that is changing around you (and *that* is a given).

I'm not sure if you're invoking some law of physics here, but inertia
does not ignore everything else -- even if it actually offers
resistance to change, it does not ignore it.

> So unless you have something exotic like /usr mounted off a central
> server, or want / on LVM (and your grub doesn't support lvm), you are
> going to need an initramfs anyway to get around the circular bootstrap
> problem.

I am yet to have a circular dependency problem in my bootstrap
sequence.  Of course, I don't have bluez installed.  I also do not have
udev or systemd installed.

> I say people should make their lives easier and just stick /usr on the
> same volume as / and be done with it. It removes a whole lot of
> painful scenarios that are going to keep on biting you as the rest of
> the world moves on and progresses

That then devolves the I/O characteristics of /usr/bin and /usr/lib
into those of /bin and /lib, which would make a slow system even slower.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*