Bug 171355 - mdadm doesn't assemble stacked arrays at bootup
mdadm doesn't assemble stacked arrays at bootup
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mdadm (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Doug Ledford
: FutureFeature
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2005-10-20 20:29 EDT by Joshua Baker-LePain
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0290
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:46:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to add some missing md file desciptor closes (1.38 KB, patch)
2006-05-02 08:06 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Joshua Baker-LePain 2005-10-20 20:29:31 EDT
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):

How reproducible:

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.
Comment 1 Doug Ledford 2005-10-26 18:08:37 EDT
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.
Comment 2 Joshua Baker-LePain 2005-10-26 20:57:44 EDT
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?

Comment 3 Doug Ledford 2005-10-31 15:21:28 EST
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.
Comment 4 Joshua Baker-LePain 2005-10-31 15:25:20 EST
Good to know.  Thanks for all the responses.
Comment 8 Jeff Layton 2006-05-02 08:06:14 EDT
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.
Comment 11 Daniel Riek 2006-08-28 18:16:46 EDT
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. 
Comment 13 Doug Ledford 2007-01-31 14:02:56 EST
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.
Comment 17 Red Hat Bugzilla 2007-05-01 13:46:27 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.