On Mon, Mar 30, 2015 at 08:54:42PM +0200, devuan.kn@??? wrote:
> Hi Steve,
>
> On Mon, Mar 30, 2015 at 7:24 PM, Steve Litt -
> slitt@???
> <devuan.kn.3c178e07a2.slitt#troubleshooters.com@???> wrote:
> > Hi Didier,
> >
> > If your post says what I think it says, you're saying that modern init
> > systems should always start services concurrently, not consecutively.
> >
> > Certainly that's a good thing, and we're working toward it, but it's
> > important to keep some perspective on the matter and do a cost/benefit
> > analysis on the alternatives.
> >
> > On my experimental Manjaro machine, systemd, which most would agree is
> > very concurrent, booted in 4 seconds. Epoch, which has absolutely no
> > concurrency at all and boots completely consecutively, booted in 8
> > seconds. How much complexity, how much indeterminacy, are we willing to
> > put up with to get A) 4 more seconds in our life every time we reboot,
> > and B) do it the more "modern" way?
>
> How fast is epoch when you throw it at a generic piece of hardware
> that you did not hand-tune it for?
>
> The problem there is that a consecutive boot system needs to probe for
> hardware and give that hardware time to show up, blocking the boot
> process in the meantime. If you have lots of hardware you need to
> probe for (as e.g. Devuan would need to out-of-the-box), then those
> wait-times can sum up really fast. And some hardware can take a very
> long time to register, so you need to be generous with those
> time-outs. On the other hand anybody without the hardware will stuck
> for the entire timeout, so you need to keep them as short as possible.

Probing for hardware is not done how you seem to think it is.
There isn't some "magic list" that you go down and blindly check if it's
there.
Instead, there's a process where the kernel discovers the hardware,
saves a record of each piece in /sys (the "uevent" and "modalias"
files), and starts the hotplug helper or sends a message via netlink.
Then, the hotplug helper/netlink daemon (hotplug, mdev, or udev)
will parse that information and load firmware/modules or create a
device.

Practically speaking, I think the only person on the list who doesn't
have their initscripts probe for new hardware every boot is the other
Karl (the one who uses a static /dev). udev and mdev probe for new
hardware every boot.
And it takes a couple seconds *here*, on an Atom N270-based system.
I've heard of people trying to make that parallel, but it typically
resulted in slower boots or unusable systems.

> > By the way, one excellent thing about the Epoch init system is that,
> > because it's completely consecutive, you can get a close look at which
> > services are taking too long to start, troubleshoot them to find the
> > bottleneck, and fix them, so that they'll start efficiently in your
> > concurrent init. The quicker everything starts in a concurrent init, the
> > less chance for race conditions.
>
> Yes and no.
>
> What happens if your filesystem has a slow day (e.g. due to some f*ing
> RAID controller deciding that it needs to do some extra sanity
> checks)? That will lead to the consecutive boot system panicking since
> its root device is not there (after some timeout), which in turn will
> lead to some poor admin having to investigate and nudge the server to
> try once more.

If your root filesystem has a slow day, you won't have /sbin/init
running:
that happens after initramfs has finished (and initramfs is fairly
serial).


Thanks,
Isaac Dunham