Bug 51911 - problems creating software raid10
problems creating software raid10
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: util-linux (Show other bugs)
roswell
i386 Linux
low Severity low
: ---
: ---
Assigned To: Elliot Lee
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-16 14:55 EDT by Jim Wright
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-21 09:42:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Wright 2001-08-16 14:55:34 EDT
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 18:00:38 EDT
Katzj is testing a fix.
Comment 2 Jeremy Katz 2001-08-21 13:53:05 EDT
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 15:08:25 EDT
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 15:10:26 EDT
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 06:00:04 EDT
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 03:20:05 EST
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 09:41:56 EST
Assigning to util-linux, where mount lives these days.
Comment 8 Elliot Lee 2002-03-07 17:22:33 EST
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.