[zfs-discuss] zfs-discuss Digest, Vol 9, Issue 48
mikko.tanner at gmail.com
Tue Jan 19 06:31:03 EST 2016
On 19.1.2016 12:09, Gordan Bobic wrote:
> On Tue, Jan 19, 2016 at 9:13 AM, Mikko Tanner via zfs-discuss
> <zfs-discuss at list.zfsonlinux.org
> <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
> This is only true of systemd-infested distros. Things have been
> working perfectly well for as long as I remember with separate
> filesystems. It is only until systemd's lazy coding and invented
> problems that this has become an issue.
> 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.
> Not supporting separate filesystems (aka stuffing most of the system
> in /usr) is a faulty design choice.
> Care to elaborate why?
I touched on that above, but main points for separate /usr are
flexibility, disaster recovery and network mounting, among others.
This also allows minimal / or even readonly root configurations with
ease. The benefits far outweigh the cons.
> There is no compelling reason at all why /usr should be necessary
> for early boot -- /bin and /sbin are there for a reason. Diverting
> from the basic POSIX assumptions just for the sake of appeasing a
> certain distro's design choices is fundamentally broken.
> What POSIX assumptions would that be? Can you cite a list, please?
Mainly that system booting shouldn't rely on stuff in /usr being
available. Please take a look at
http://www.pathname.com/fhs/pub/fhs-2.3.html, specifically the "purpose"
> TL;DR - the issue here is systemd, nothing else.
> No, it really isn't. I detest systemd for too many reasons to enumerate,
> but this is one place where Lennartware isn't to blame.
Most definitely systemd is the main reason for this whole combined /usr
brouhaha. Because of how Lennart & co have made certain
systemd-assimilated low level functionalities (udev, dbus et al) to hard
depend on the rest of systemd, one can't easily split them out of /usr
Embrace and extend.
> 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.
> The entire premise that you want to make sure that not both / and /usr
> fill up due to a misconfiguration somewhere else is ridiculous. That is
> what quotas, monitoring and sensible output placement are for.
I fail to see how contingency planning is ridiculous.
> The irony in using this as a reason to split /usr off to a separate FS is in
> the fact that if you don't set up quotas, since all the FS-es share the same
> pool, ANY FS filling up will cause disk space depletion on ALL FS-es, so
> the entire premise is outright broken.
Please don't set up strawman arguments. Quota management is way easier
with ZFS than f.ex. LVM/ext4 so there is no reason not to. Also,
reservations. Besides, ZFS is in the minority here and this is only
tangentially related to the systemd problem, albeit for the same reason.
More information about the zfs-discuss