On Dec 9, 2013, at 11:47 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Mon, 9 Dec 2013 12:42:21 -0700 > Chris Murphy <li...@colorremedies.com> пишет: > >> >> On Dec 9, 2013, at 3:33 AM, Thomas Bächler <tho...@archlinux.org> wrote: >> >> I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm >> settle twice. >> >> The actual culprit though is dmraid-activation.service which is enabled by >> default (why?) and Wants=systemd-udev-settle.service. >> dmraid.activation.service also has the #2 biggest blame hit: >> 4.551s dmraid-activation.service >> > > There is no such service on openSUSE, which OP has :) Right, sorry this is Fedora 20, specifically the live install. > >> So why is this enabled by default when there's no dmraid at all, and never >> has been dmraid metadata on any attached device? >> > > The obvious question is - and how should system know it? Who is > responsible for activating it again after you have added dmraid devices? The argument being used in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=964172 Is that the dmraid package isn't installed if the user hasn't created a dmraid device at install time; except with live installs which will always have it installed (and enabled) and the user is expected to disable dmraid if they don't use it. It doesn't work this way for XFS devices, or md devices, or LVM devices. So this is pretty puzzling that by design the user is responsible. Maybe it just makes it easier for dmraid to go away. > > Is it possible to trigger dmraid from some udev rule similar to what > mdadm currently does? Sure, that seems to work pretty well. It's fast whether md devices exist or not. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
