Bug 704890 - mdadm gets executed before multipath
Summary: mdadm gets executed before multipath
Keywords:
Status: CLOSED DUPLICATE of bug 433762
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts
Version: 5.6
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-15 19:31 UTC by Raul Mahiques
Modified: 2012-03-27 13:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-27 13:12:00 UTC


Attachments (Terms of Use)

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


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