Bug 1039781

Summary:	dmraid-activation.service enabled by default, causes slow boot
Product:	[Fedora] Fedora	Reporter:	Chris Murphy <bugzilla>
Component:	dmraid	Assignee:	LVM and device-mapper development team <lvm-team>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	agk, bmr, dwysocha, heinzm, lvm-team, prajnoha, prockai, zkabelac
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-10 11:17:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	963210

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 ***