when startup delays become bugs (dmraid)

[Hans de Goede]

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.

Regards,

Hans


*) Not dmraid's fault, just the price we pay for reverse-engineering
these firmware raid on disk meta data format.