Brian Dolbec posted on Mon, 03 Aug 2015 00:59:07 -0700 as excerpted: > On Mon, 3 Aug 2015 00:47:24 -0700 Brian Dolbec <dol...@gentoo.org> > wrote: >> >> On Mon, 3 Aug 2015 00:22:42 -0700 "Daniel Campbell (zlg)" >> <z...@gentoo.org> wrote: >> >> > I'm having a hard time understanding why we need daemons to handle >> > our filesystems. Can you give me a use case that /etc/fstab is >> > insufficient for solving?
>> It is about defining proper dependencies and not blindly returning a >> success result when there were actual failures to start some files >> systems. >> So in some ways it is a bugfix. But it is actually a re-design which >> will overcome shortcomings/limitations in the fstab, netmount, >> localmount designs. > > For the average joe user that only has a few fstab entries, /boot, > /root,/home. swap... > > It won't mean much if anything other than an un-needed change. Since it > works for them. > > But for a systems administrator configuring servers with virtual > machines, services depending on certain or multiple filesystems being > up, etc... It can mean a BIG difference. It is the more complicated > systems that are hitting the limitations of the current fstab system. > not the simple user with a standard/basic handbook install. [TL;DR folks, skip to last paragraph.] Any time there's nested mounts, say /var/log on /var, on /, or /usr/local on /usr, on /, there's dependency issues that the current openrc localmount and netmount services don't deal with explicitly. If it happens to work, great, but sometimes it doesn't. Back on openrc, I used to have this problem with some custom bindmounts I did for a chrooted service. They were nested mounts, bind-mounting something that itself was on a separate filesystem, and openrc's localmount just doesn't deal well with that sort of thing, so I had to roll my own latelocalmount service, with the mounts marked noauto so localmount didn't try to mount them before their source filesystems were mounted, then explicitly mounted by name, in the latemount service. If I'd have had multiple layers of nesting, I would have needed multiple layers of mounting services. That gets to be a nightmare pretty quickly, all because openrc's existing mount services handle things en-mass, there's no way to explicitly specify dependencies of one mount on others, either at the mount level, or with the service, since individual mount services don't exist, only the en-mass localmount and netmount services. It was and remains a mess. To my very pleasant surprise, when I switched to systemd, most of those mounts "just worked", because systemd uses an internally multiplexed individual mount approach instead of the en-mass approach openrc currently uses, and systemd automatically calculates dependencies. The one that systemd did NOT handle correctly by default was because it was a symlink, and apparently systemd's automated dependency handling doesn't deal with symlinks. (Not that I can blame it, symlinks can go circular or dangling, and the calculations get complex pretty quickly. But it handles the non-symlink cases _surprisingly_ well!) And that one had a simple fix, adding a single line to the service unit depending on that mount (it was an early-boot service so had the default deps of all mounts done turned off, but still would have detected the need for the mount based on path, if it was a straight path, not symlinked), making explicit the mount dependency so systemd could follow the dependency logic and would ensure that mount was completed before trying to start the service that depended on it. Long story short, systemd has upped the expectancy by handling these things automatically in most cases and making it very simple to add explicit mount deps where systemd's automatic handling fails, so other init systems must either match that expectancy now too, or fall further behind. The expectations have changed, and forcing the admin to jump thru a series of complex hack hoops to get nested mounts, etc, working, simply doesn't cut it any more. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
