Bug 704890

Summary:	mdadm gets executed before multipath
Product:	Red Hat Enterprise Linux 5	Reporter:	Raul Mahiques <rmahique>
Component:	initscripts	Assignee:	initscripts Maintenance Team <initscripts-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.6	CC:	bmr, cherguet, chorn, hmilz, notting
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-27 13:12:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Raul Mahiques 2011-05-15 19:31:34 UTC

Description of problem:
mdadm gets executed before multipath, therefore software raid will not use multipath devices.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create a software raid using two multipath devices.
2. Reboot the machine.

  
Actual results:
mdadm gets executed before multipath and it will lock the devices with a software raid on them, multipath is executed afterwards and will not be able create a multipath device fot them.

Expected results:
Multipath is executed before mdadm so that mdadm can use multipath device instead of direct ones (single path).


Notes:
If there is any situation where mdadm needs to be executed before multipath, a simple configuration file and an "if" statement could be added to solve let the administrator chose the behaiviour.

Comment 1 Bill Nottingham 2011-05-16 18:21:32 UTC

This is true, but attempting to support this opens up the Pandora's box of continually stacking different storage subsystems on top of each other in infinite combinations.

(i.e., multipath -> raid -> lvm or multipath -> lvm -> raid, etc. And don't forget dmraid!)

We're intending to fix this for RHEL 7 by supporting dependency-based device initialization that brings up devices properly based on the configuration, rather than just running commands in a defined order. But that's not backportable to RHEL 5 or 6.

Comment 2 Harald Milz 2011-05-17 08:16:32 UTC

Bill, thanks for adding your comment. A question might be if a customer needs devices initialized and stacked differently from the default, and needs to modify rc.sysinit to get this done, will we support this?

Comment 3 Raul Mahiques 2011-05-17 14:25:12 UTC

Bill, but wouldn't it make more sense to start multipath before mdraid?

Comment 4 Bill Nottingham 2011-05-17 18:08:27 UTC

It was added for bug 480627, in order to support MD on raw iSCSI. I suppose in general it makes sense to be after multipath, but that's a behavior change.

Comment 5 Christian Horn 2011-10-27 16:48:50 UTC

Not many chances to change the order mdadm<->multipath in RHEL5 and more I guess.

Wondering on feasibility for RHEL6..

Comment 6 Bill Nottingham 2011-10-27 19:13:04 UTC

Unlikely we're not going to change the existing orders without changing the infrastructure to assemble disks on demand first (i.e., if we're going to fix it, we'll fix the whole hardcoded sequence problem.)

Comment 8 Bryn M. Reeves 2012-03-27 13:07:28 UTC

Seems to be a dupe of bug 433762 (closed WONTFIX in 2008).

Comment 9 Bryn M. Reeves 2012-03-27 13:12:00 UTC


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