Bug 51911 - problems creating software raid10
Summary: problems creating software raid10
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: util-linux
Version: roswell
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-16 18:55 UTC by Jim Wright
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-02-21 14:42:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Jim Wright 2001-08-16 18:55:34 UTC
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
correctly.

Version-Release number of selected component (if applicable):


How reproducible:
Unsure

Steps to Reproduce:
As above

Additional info:

Comment 1 Michael Fulbright 2001-08-17 22:00:38 UTC
Katzj is testing a fix.

Comment 2 Jeremy Katz 2001-08-21 17:53:05 UTC
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?

Comment 3 Jim Wright 2001-08-21 19:08:25 UTC
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
install.

After the machine was up, I editted the /etc/raidtab file and did the mkraid
commands.  Then
did a mkfs and an e2label.  Added this to fstab using the label.  System booted
but didn't
"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
to figure
out all the details of how it failed.

Comment 4 Jeremy Katz 2001-08-23 19:10:26 UTC
If it was created post-install and doesn't work, this is a mount problem, not
anaconda... reassigning.

Comment 5 Bernhard Rosenkraenzer 2001-09-11 10:00:04 UTC
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).


Comment 6 Jim Wright 2002-01-30 08:20:05 UTC
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.

Comment 7 Bernhard Rosenkraenzer 2002-02-21 14:41:56 UTC
Assigning to util-linux, where mount lives these days.

Comment 8 Elliot Lee 2002-03-07 22:22:33 UTC
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.


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