Red Hat Bugzilla – Bug 171355
mdadm doesn't assemble stacked arrays at bootup
Last modified: 2007-11-30 17:07:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050811 CentOS/1.0.6-1.4.1.centos3 Firefox/1.0.6
Description of problem:
I wanted to create a RIAD50 array by striping 2 software RAID5 arrays. At system boot, the 2 RAID5 arrays get started, but the RAID0 stripe doesn't. This is my mdadm.conf file:
DEVICE /dev/sd[a-e]2 /dev/sd[f-p]1 /dev/md[0-1]
ARRAY /dev/md0 UUID=3f4b2946:8076c1b7:ee03d55f:4d15d6db auto=md
ARRAY /dev/md1 UUID=dce0f650:5b1ddd82:b601d35e:b52320c9 auto=md
ARRAY /dev/md2 UUID=dfb2bd6a:b29d48bb:1d103b49:c32f3dbf
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create the 3 RAID arrays above. md0 and md1 are 8 disk RAID5s, and md2 is a RAID0 of md0 and md1.
2. With the above mdadm.conf in place, reboot.
Actual Results: After startup, only md0 and md1 are active.
Expected Results: All 3 arrays should be running.
I upgraded to 1.11.0 from upstream, and this properly assembled the stripe (md2) with the same mdadm.conf file.
This is unlikely to be fixed anytime soon. RHEL4 was not intended to support
stacked md arrays, and this feature has not been requested often enough to make
it a high priority.
Fair enough. The main thing I was going for was resistance to multiple disk
failures without sacrificing 1/2 the raw drive space (so no RAID10). RAID6, of
course, would be perfect, but I hit (and filed) bug 171354. That one I'd love
to see fixed.
As an aside, I'm assuming that bug 154561 will end up the same as this one?
Not necessarily. There are enough mdadm bugs present that we may do a wholesale
update to the latest mdadm release. If that happens, this and quite a few other
mdadm bugs will get resolved.
Good to know. Thanks for all the responses.
Created attachment 128479 [details]
patch to add some missing md file desciptor closes
This patch seems to cure the problem on my test rig. This is respun from Neil
Brown's upstream patch:
The problem here is that early on, when the underlying md devices aren't yet
started the md device nodes are opened and an ioctl(...,BLKGETSIZE...) is
called. This returns 0 since the device isn't started yet. This fd is never
closed, however, so later ioctl() calls to this device node also return 0, even
after the device is started.
This fixes this by adding in the missing md file decriptor closes and forcing
them to be reopened correctly.
The component of this request is planned to be updated in Red Hat enterprise
This enhancement request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux maintenance release.
Product Management has requested further review of this request by Red Hat
Engineering, for potential inclusion in a Red Hat Enterprise Linux Update
release for currently deployed products.
This request is not yet committed for inclusion in an Update release.
Code similar to the patch posted in this bug is already present in the 1.12.0
version of mdadm that we are updating to in RHEL4.5. Therefore, this issue
should be solved by the base 1.12.0 update. Marking as MODIFIED.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.