Red Hat Bugzilla – Bug 142078
mdadm can't assemble multipath devices
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922
Description of problem:
After configure a multipath md device, if one path goes way, the mdadm
can't automatically assemble the device after reboot.
It seems to me that the mdadm would always go thru the complete disk
list - if one of them is not available, it would abort the whole
"Assemble" process. Doesn't this defeat the purpose of multipath ?
In "Steps to reproduce", I use devlabel to avoid the device rename
issue but the problem here is not so much about devlabel but about
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add two paths to the same disk (sdd1, sdh1)
[root@localhost root]# devlabel add -d /dev/sdh1 -s /wendy --multipath
MULTIPATH: /wendy_multipath# -> /dev/sd#1
/wendy_multipath0 -> /dev/sdd1
/wendy_multipath1 -> /dev/sdh1
Added /wendy to /etc/sysconfig/devlabel
2. Create the md device accordingly.
[root@localhost root]# mdadm -C /dev/md0 --level=multipath
--raid-disks=2 /wendy_multipath0 /wendy_multipath1
3. Do something with the /dev/md0.
4. Remove /dev/sdh1 link.
6. The "mdadm -A /dev/md0 /wendy_multipath*" command will fail with
mdadm: cannot open device /wendy_multipath1: No such device or address
mdadm: /wendy_multipath1 has no superblock - assembly aborted
Actual Results: Customer is required to manually assemble the md
device (and knowing which link is down). This has caused confusion and
Expected Results: Since this is a multipath setting, can't mdadm just
loops thru the dev list and pick up whatever it can get ?
Note that if I manually do (knowning /wendy_multipath1 is gone):
mdadm -A /dev/md0 /wendy_multipath0
The md device would come up without problem.
Would you take a look to see if this bug is the likely cause of the problem in
There are actually two problems in that IT. The first is that the non-zero LUNs
are not being configured automatically. When that was worked-around by having
them use "scsi add-single-device" they still have a problem assembling the
multipath set. The customer reports that md says: "Device or resource busy" on
each of the devices and only adds 1 of the 2 disks into the md device. The log has:
multipath: array md1 active with 1 out of 1 IO paths
Is this md problem likely to be caused by the bug in this BZ?
The fact that mkinitrd skipped any raid devices with multipath as the level
prior to RHEL3 U5 was a prima facia cause of certain failure. Now that this bug
is resolved, any remaining issues that customers might have would be different
and would require a new bugzilla to be entered.
Marking this issue as closed, fixed in current release. RHEL3 U5 latest kernel
available is 2.4.21-32.0.1.EL, (first security errata in U5).