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): mdadm-1.6.0-2 How reproducible: Always 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. Additional info: 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? Thanks.
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: http://cgi.cse.unsw.edu.au/~neilb/source/mdadm/patch/applied/009CloseMdfd 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 Linux 4.5. 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. http://rhn.redhat.com/errata/RHBA-2007-0290.html