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 correctly. Version-Release number of selected component (if applicable): How reproducible: Unsure Steps to Reproduce: As above Additional info:
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 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.
If it was created post-install and doesn't work, this is a mount problem, not anaconda... reassigning.
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.