Hide Forgot
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 mdadm itself. Version-Release number of selected component (if applicable): kernel-2.4.21-20.EL How reproducible: Always 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. 5. Reboot 6. The "mdadm -A /dev/md0 /wendy_multipath*" command will fail with errors: 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 complaints. 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. Additional info: IT# 50469
Doug, Would you take a look to see if this bug is the likely cause of the problem in IT 68230? https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=68230 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? Tom
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).