initramfs/udev/mdadm/lvm2 integration

[Phillip Susi]

Scott James Remnant wrote:
> On Tue, 2007-09-11 at 16:16 -0400, Phillip Susi wrote:
> 
>> Kees Cook wrote:
>>> In Gutsy, the udev rules work for systems that have been set up
>>> correctly using UUIDs[1] in their /etc/fstab.  If there are
>>> (non-degraded) situations where LVM-on-MD does _not_ boot, it should be
>>> considered a bug, and a new report should be opened.
>> LVM-on-MD works, but is a hack.  LVM on dmraid does not work ( see bug 
>> #129285 ).  The discussion for the proper fix is at:
>>
>> https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain
>>
> LVM-on-MD is not a "hack", what part of it do you consider to be hacky?

It is a hack because right now udev does not scan devices as they are 
added and activate them if a complete raid set has been found.  Instead 
it just runs mdadm every time a new disk is detected, and it scans 
everything it can find in /dev that looks like a hard disk partition and 
tries to activate all that it finds.

> Err, what's LVM-on-dmraid?  The reason that doesn't work is because I've
> never heard of it.

LVM on top of dmraid ( hardware fakeraid ).  See the above bug.

>> The LVM and dmraid tools are fundamentally broken as designed with 
>> respect to udev and need fixed to support being told what devices to 
>> muck with by udev instead of scanning for things that look proper 
>> devices in /dev.
>>
> Yes, that's true; is this what you mean by "a hack" ?

The whole point of udev is that it deals with the one newly detected 
device and intelligently decides what to do with it based on system 
policy using scripts, as opposed to the old way of just looking for all 
dev nodes matching known patterns in /dev at some point during a boot up 
script.  The hack is that the old method has simply been set to be run 
over again when new hardware is detected, instead of only once at boot.

> The difficulty is, the bigger and more complex the server, the longer
> you can normally expect to wait.  There are complaints that the three
> minute timeout isn't enough for people's disk arrays on a cold morning.

Hence the configurable boot parameter.  3 minutes seems a good default 
for "most" configurations. For desktops or servers being booted up with 
an admin at the console, being told a drive is still missing early and 
given the chance to decide that something is wrong and that drive WON'T 
come up so skip it, is handy.