[zfs-discuss] zfs-discuss Digest, Vol 9, Issue 48
mikko.tanner at gmail.com
Tue Jan 19 09:53:37 EST 2016
On 19.1.2016 13:49, Gordan Bobic wrote:
> Merging /sbin:/usr/sbin, /bin:/usr/bin and /lib:/usr/lib has
> been a long
> time coming. Solaris did this nearly 10 years ago.
> The split is there for a reason, one of which is single mode and
> system rescue (booting or otherwise). The point is, one shouldn't
> rely on /usr being mounted early in the boot process because often
> it is on a separate filesystem or even mounted over NFS. This gives
> more administrative flexibility and also allows upgrading user
> software in a centralized source, f.ex.
> Both of the points here are erroneous:
Hardly, but I will humour you :)
> 1) For rescue, initramfs is now generally used. If you look at what
> initramfs includes these days, you will understand why. Set
> rd.break=pre-mount as your kernel boot parameter and you have quite
> extensive intervention capabilities. In most foreseeable cases, you
> would not have need for what is in /bin and /sbin for such cases.
Initrd doesn't include anything that it hasn't been configured to
include. I know full well what it contains and does, and it is _not_
meant to be a full rescue environment. There is hardly any point in
including more than the barest minimum necessary for its purpose - mount
the root and pivot into it.
If your system is broken enough that you can't mount the root, then
often you can't even read the initrd itself. Which brings me to the next
> 2) NFS hasn't been supported for anything rootfs related for a couple of
> years now because of the move by most distributions from using SUID bits
> on executables that require them to using file capabilities - which
> aren't supported by NFS.
Works fine for mine and my employer's use cases with modern kernels
(>4). The trick is in knowing how to set things up properly.
Also, continuing the previous point. Rescuing a non-booting system when
you can't fix/mount the root with initrd-supplied tools. Either you can
physically visit the system, plug in a rescue USB stick and go from
there. Or you can remote into the system (IPMI, serial console...) and
network boot a premade rescue environment. Which is easier?
Which brings me to the third point about this systemd mess: network
booting. Since systemd wants everything to live in /usr (being a subset
of root), you will need to mount/share much larger filesystem trees for
a simple network boot environment than what would be possible with split
All this is unnecessary added complexity just for the sake of doing
things "the systemd way" (aka. Embrace and Extend).
> Flexibility point is nebulous and questionable. For the other points I
> explained why they are erroneous above.
How on earth do you twist having the ability to separately mount / and
/usr being nebulous and/or questionable? For the rest, see above.
> LiveCDs are implicitly running on read-only media and they don't involve
> splitting off /usr to a separate FS, so I'm not sure what point you are
> trying to make here.
LiveCDs pack the whole root tree into one large archive for 2 reasons:
simplicity and compression efficiency. This however has nothing to do
with the argument itself, since you could just as well have each
filesystem as a separate loopback file on the CD and mount as needed.
Systemd however makes splitting impractical here as well.
> There really is no sane reason to split /usr to a separate FS.
> There are many reasons for the split. Please don't assume that your
> use case is the only case.
> I'm not assuming anything - you just haven't made a compelling case to
> the contrary. :-)
Hogwash. I am not the one who needs to defend separate /usr, even though
I have done just that to humour you. You say you dislike systemd, but
still espouse the filesystem layout forced by systemd. Please elaborate.
Besides, you aren't providing any counterpoints to the above.
> I fail to see how contingency planning is ridiculous.
> If you can specify an exact contingency you are planning for here, then
> I'm sure the rest of us here can help you come up with a sensible
> solution (and I am stating that separating off /usr isn't a sensible
Please stop with the condescending attitude. I already provided many
reasons for split /usr. As I see it, you need to be a lot more careful
with that word "sensible", as your sensibilities aren't necessarily
shared by other people.
> And as I said before, if you want to do things the LVM/ext4 way, you are
> welcome to do so.
Why the hostility? The fact is that systemd causes a host of issues with
system booting, which also trickle down to ZFS use cases like here.
I definitely prefer ZFS over LVM/ext, there is no question that it is
the superior scaffolding. The systemd problems however affect LVM/ext
setups as well.
More information about the zfs-discuss