initramfs/udev/mdadm/lvm2 integration

[Scott James Remnant]

On Thu, 2007-09-13 at 10:45 -0400, Phillip Susi wrote:

> 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.
> 
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.

> > 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.
> 
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.

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070913/319196e6/attachment.pgp