Red Hat Bugzilla – Bug 51911
problems creating software raid10
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.6-xfs i686)
Description of problem:
This next bit is pushing the limits and I'm not sure it is something
I would do on a "real" system, but... I was trying to create a partition
using software raid 10. I created a mirror of two devices as /dev/md7,
another mirror as /dev/md8, and a stripe called /dev/md9 which consisted
of /dev/md7 and /dev/md8. I ran e2label to label the filesystem and then
I used the label in the /etc/fstab file.
This led to havoc, when the mount command went out to search for this
label and basically couldn't do the right thing. So I switched to
"old style" fstab listing the device as /dev/md9 and things worked
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Katzj is testing a fix.
Looking at this some more... are you creating the raid10 in anaconda or
post-install? Or are you trying to upgrade something set up like this?
This was a fresh install. Initially I tried to create the raid10 using
anaconda. I wasn't sure
exactly what I wanted, so I ended up not creating a raid10 filesystem during the
After the machine was up, I editted the /etc/raidtab file and did the mkraid
did a mkfs and an e2label. Added this to fstab using the label. System booted
"do the right thing" when it tried to mount the filesystem. I quickly changed
to using /dev/mdX
in the fstab and all was well.
Sorry for my vagueness as to "do the right thing". It failed, my instinct said
the fix was to use
/dev/mdX for mounting, which worked. I did not spend much time playing around
out all the details of how it failed.
If it was created post-install and doesn't work, this is a mount problem, not
Were the raid modules loaded when trying to mount the filesystem initially?
If not, this is not a bug: Accessing the /dev/mdX device auto-loads the
required modules, after which the label could be found.
But mount is not supposed to auto-load modules just to see if there are any
devices, so mounting an md device by label can't work if you didn't load the
modules. It'll just probe the partitions belonging to the raid device (and
obviously not do the right thing).
cruising through bugzilla and found that this was in limbo waiting for more info
from me. oops.
I believe the issue is this:
mirror drive a and b; call this x
mirror drive c and d; call this y
stripe raidset x and y; call this z
now, if I put a filesystem label on z and try to mount it using labels, it
doesn't work. the raid drivers are all loaded and operating. however, when the
mount process goes and looks for the label written on the partition, it finds a
matching label on raid device x. and then it mounts x. but since this is part
of a stripe, things go wonky.
obviously, it has been a while and I'm going by memory. the above description
seems suspect to me. it may in fact have been
stripe drive a and b; call this x
stripe drive c and d; call this y
mirror raid set x and y; call this z
then it makes more sense to me that the mount would incorrectly access x using
the label instead of z.
mounting raid10 with /dev/md? instead of LABEL=foo works.
Assigning to util-linux, where mount lives these days.
Bleah, this bug sucks to fix. I'm going to add something that ignores a device
if it has a raid superblock at the end - hopefully that will fix it.