initramfs/udev/mdadm/lvm2 integration

[Phillip Susi]

Scott James Remnant wrote:
> Yeah, there's no way to tell LVM or MDADM that "hey, I have this block
> device, don't scan just add the knowledge about this device to your
> existing knowledge".
> 
> Which, if we could do that, would centralise the logic in udev about
> which devices were for LVM or MDADM, etc.

Exactly.  In fact, I would prefer to have udevdb keep track of what type 
and the id of the volume to which the device belongs rather than the 
tool, then when a new disk is added which belongs to the same volume, 
pass both devices to the tool and ask it to try and activate the volume 
using those devices.

> The problem is that you don't ever find out that you need the parameter.
> 
> You boot your server, it boots degraded after three minutes; how do you
> know that it needed a longer bootdelay?  That's a "fail to worst case
> scenario" solution.  Failing to boot at all does have the advantage that
> you *know* you need to change something.

Yes, but you may not be ABLE to change something if it is unattended and 
won't boot up.  At least if it boots degraded, it is available for you 
to remotely admin and mdadm should email you that it is running 
degraded, and automatically try to rebuild using a hot spare if 
available.  Then you can remotely start offlining unimportant services, 
tell users you will be going down, start backing up, mail the datacenter 
a new drive and ask them to replace it, etc.

If the server is attended, then the admin will see it sitting there 
beeping and saying it can't find the last drive, and if he thinks 
there's nothing wrong with the drive but it just takes a while, he can 
hit a key to tell it to keep waiting.