Bug 1039781 - dmraid-activation.service enabled by default, causes slow boot
Summary: dmraid-activation.service enabled by default, causes slow boot
Keywords:
Status: CLOSED DUPLICATE of bug 964172
Alias: None
Product: Fedora
Classification: Fedora
Component: dmraid
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: WhyWeBootSoSlow
TreeView+ depends on / blocked
 
Reported: 2013-12-10 01:08 UTC by Chris Murphy
Modified: 2013-12-10 11:17 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-10 11:17:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Chris Murphy 2013-12-10 01:08:04 UTC
Description of problem:
Default DVD and Live Desktop installs of Fedora 20 (final TC5) have dmraid-activation.service enabled by default, even when there are no dmraid devices present, causes slow boot times itself and also because it pulls in udevadm settle.

Version-Release number of selected component (if applicable):
dmraid-1.0.0.rc16-23.fc20.x86_64

How reproducible:
Always

Steps to Reproduce:
install, boot, systemd-analyze

Actual results:
systemd-analyze blame

4.551s dmraid-activation.service
1.267s systemd-udev-settle.service


Expected results:
Either dmraid-activation.service isn't spawned at all unless there's a dmraid device present, or at least it shouldn't take such a huge amount of time. And likey the same as for LVM, it probably shouldn't be bringing in udev settle either which takes up even more time.

Additional info:

Comment 1 Peter Rajnoha 2013-12-10 09:47:03 UTC
(In reply to Chris Murphy from comment #0)
> Expected results:
> Either dmraid-activation.service isn't spawned at all unless there's a
> dmraid device present, or at least it shouldn't take such a huge amount of
> time. And likey the same as for LVM, it probably shouldn't be bringing in
> udev settle either which takes up even more time.

This is probably more a question of default anaconda installation set. If there are no mdraid devices during installation, the mdraid probably should not be installed (there was a discussion once about this, though I don't remember the outcome in detail at the moment, I'll try to find the discussion thread...).

Then whenever someone needs dmraid devices, the dmraid pkg should be installed manually.

I doubt dmraid will change the activation scheme - it would need to have something like LVM adopted - the event-based activation and that's not a straightforward change (btw LVM activation is already event-based with the help of new lvmetad daemon, so LVM doesn't need udev settle anymore since F19).

What I see as the best way to go here is to not install dmraid by default in anaconda...

Comment 2 Peter Rajnoha 2013-12-10 09:48:58 UTC
(In reply to Peter Rajnoha from comment #1)
> This is probably more a question of default anaconda installation set. If
> there are no mdraid devices during installation, the mdraid probably should

I mean dmraid, not mdraid.

Comment 3 Peter Rajnoha 2013-12-10 09:50:54 UTC
Hmm, but in default F20 installation, the dmraid is not installed anymore. So it's probably just the Live spin that still uses it.

Comment 4 Peter Rajnoha 2013-12-10 11:12:56 UTC
OK, so here's some context which advocates using dmraid in live spins: bug #964172 (also https://lists.fedoraproject.org/pipermail/devel/2013-May/182911.html mentioned there).

Comment 5 Peter Rajnoha 2013-12-10 11:17:32 UTC
Marking this one as dup of 964172 - let's discuss it at one place.

*** This bug has been marked as a duplicate of bug 964172 ***


Note You need to log in before you can comment on or make changes to this bug.