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.
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.
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?
Bill, but wouldn't it make more sense to start multipath before mdraid?
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.
Not many chances to change the order mdadm<->multipath in RHEL5 and more I guess. Wondering on feasibility for RHEL6..
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.)
Seems to be a dupe of bug 433762 (closed WONTFIX in 2008).
*** This bug has been marked as a duplicate of bug 433762 ***