On Fri, 17.05.13 09:05, Hans de Goede (hdegoede@xxxxxxxxxx) wrote: > Hi, > > On 05/17/2013 01:21 AM, Lennart Poettering wrote: > >On Thu, 16.05.13 13:44, Adam Williamson (awilliam@xxxxxxxxxx) 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: https://bugzilla.redhat.com/show_bug.cgi?id=964172 I also filed this bug against anaconda, so that for the non-livecd installs we don't even get dmraid installed... https://bugzilla.redhat.com/show_bug.cgi?id=964175 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
