Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues
Daniel Pittman <firstname.lastname@example.org> writes:
> Goswin von Brederlow <email@example.com> writes:
>> Daniel Pittman <firstname.lastname@example.org> writes:
>>> Petter Reinholdtsen <email@example.com> writes:
>>>> [Goswin von Brederlow]
> [... waiting for enough devices to show up ...]
>>>> The only known solution today is to add a long delay during boot to try to
>>>> increase the chance of having all devices available when they are
>>>> needed. :(
>>>>> The big question is how long do you wait?
>>> Please, for the love of everything sane, ask a low priority debconf question
>>> with a default of five minutes Ã¢â?¬â?? and display a note in the initramfs about
>>> what you are waiting for, and how long.
>> For most people that is about 4 minutes and 30 seconds too long. And don't
>> forget that this needs to be multiple times. Usualy once in the initramfs
>> and once in the real system. But if devices are really multilayered you can
>> end up having to do this for every layer.
>> The multipath waits for both its paths. Then the raid waits for all its
>> devices. Then the drbd waits for both its other hosts to boot. That is 15
>> minutes already in case of a bad error.
>>> (Actually, the countdown from the DRBD init script, including the prompt to
>>> override the configured wait time, would be absolutely wonderful to have
>>> here, since it gives excellent feedback, a good UI to bypass things, and is
>>> generally quite informative.)
>> Which I think is a verry good compromise. As long as you have a keyboard
>> to press ctrl-c. :)
>> One small problem though. This requires that you know beforehand what
>> devices to expect at all.
> It took me two tries to understand what you were saying here. Yes, that would
> be an issue, even if it can be solved in some cases. The "waiting for" is
> "for the root device to show up", and what is happening is event-driven stuff
> is building â?? and, hopefully, eventually that creates the root device.
> So, either the system would need to "document" the path to the root device
> somewhere, and use that to drive the "what we are waiting for next" part, or
> you would need to treat that as a global timeout.
> The later would at least reduce it from one-wait-per-device worst case,
> I guess. ;)
Waiting for the root device is only relevant for the initramfs. I don't
see a problem there. You just wait till the root device is there and
start up whatever comes along till then. Maybe you start too much but
that doesn't matter.
The bigger problem is later during boot when you need to wait for all
devices to appear so /usr, /home, ... can be mounted. One way to solve
this would be to have the fsck and mounting of filesystems wait for the
specified timeout for the device to appear as well. So even more event
Another issue is that in the case some device is missing and you do run
into a timeout things have to timeout in the right order. E.g. /dev/md1
waits for /dev/sdc1 and lvm waits for /dev/md1. Then /dev/md1 has to
timeout first and come up degraded so the lvm starts successfully. And I
think at that point the only solution is to know the layering of devices
so the layers can timeout lowest to highest.