when startup delays become bugs (dmraid)

Lennart Poettering mzerqung at 0pointer.de
Fri May 17 12:33:33 UTC 2013

On Fri, 17.05.13 09:05, Hans de Goede (hdegoede at redhat.com) wrote:

> Hi,
> On 05/17/2013 01:21 AM, Lennart Poettering wrote:
> >On Thu, 16.05.13 13:44, Adam Williamson (awilliam at redhat.com) wrote:
> >
> >>On Thu, 2013-05-16 at 20:41 +0000, "J├│hann B. Gu├░mundsson" wrote:
> >>>On 05/16/2013 08:17 PM, Bill Nottingham wrote:
> >>>
> >>>>We *could* drop all the assorted local storage tools from @standard and just leave
> >>>>them to be installed by anaconda if they're being used to create such
> >>>>storage. They'd have to remain on the live image, though, and so this would
> >>>>not help installs done from the live images.
> >>>
> >>>Is not the live images exactly the place where we dont want enterprise
> >>>storage daemons?
> >>
> >>dmraid is hardly enterprise, though. It's used for all firmware RAID
> >>implementations aside from Intel's, and it's not unusual for any random
> >>system to be using firmware RAID.
> >
> >As I understood this non-intel fakeraid is actually pretty much the
> >exception...
> I'm afraid that is not the case, back when I worked on anaconda we had
> tons and tons of dmraid (so non intel firmware raid) related bugs, mostly
> in dmraid itself (*), and yes this is 2 years ago but I don't believe
> the situation will have changed drastically all amd motherboards for
> example will still need dmraid if they are using the motherboard build
> in raid, as well as jmicron controllers slapped on for extra sata ports,
> and even some pci(-express) add in "raid" cards need dmraid because they
> are just firmware raid. Also various raid + ssd all in one contraptions
> are being build, which likely also need dmraid.
> So at least in the live images having dmraid by default is a must IMHO,
> otherwise we may end up writing to one disk of a mirror without marking the
> mirror dirty, which is not good, not good at all.
> But I think we can still do better here while keeping dmraid by default,
> it is highly highly unlikely for an installed system which is not using
> dmraid to all of a sudden get a dmraid set without a re-install. It is
> possible, but this requires an advanced user to be doing all kind of
> manual tweaking, and we can just document that in this case one more
> tweak is necessary.
> So I would like to suggest that we simple make the dmraid service write
> a (very simple) config file at the end of its first run (so its writes
> the config file only if it does not exist), and then use the contents
> of that file to conditionally start dmraid from then on.
> Note I believe this really needs to be a config file, and not a if
> no dmraid-sets where found disable service kind of magic, so that if
> a dmraid set was available but temporarily becomes unavailable, we
> don't end up disabling the service and then if the set is fixed /
> restored, we still don't do the right thing.
> If others (esp Heinz and Peter, added to the CC) agree this would be
> a good solution to no longer dragging in systemd-udev-settle into
> every systems boot, I think we should schedule fixing this for F-20.

I have filed a bug for this now:


I also filed this bug against anaconda, so that for the non-livecd
installs we don't even get dmraid installed...



Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list