[NTLUG:Discuss] Software RAID-1 success and questions.

[Dan Carlson]

----- Original Message -----
From: "Richard Geoffrion" <ntlug at rain.lewisville.tx.us>
To: <discuss at ntlug.org>
Sent: Thursday, June 27, 2002 11:05 AM
Subject: Re: [NTLUG:Discuss] Software RAID-1 success and questions.


> . . .
> I created an alternate lilo.conf file and pointed the boot device to
> /dev/hda.   I reran lilo and was successful in starting the linux system
on
> either disk.  Which had the side benefit of testing fail-safe recovery on
> the RAID array.   Thanks!  It's funny though. I never had to tell lilo to
> use /dev/hdb as the boot device.  It seems that it got that information
from
> /etc/raidtab.  ( I configured /hdc as raid-disk 0.  I assume that since
it
> was the primary device for /dev/md0, it got the boot loader.  But why not
> BOTH disks?  The /boot directories were RAIDed as /dev/md0! )

I don't think lilo is aware of raid and I don't think it looks at raidtab.

You should use the boot= option in your separate lilo.conf files to specify
the drive you want mbr modified on.

It is possible that when you switch your boot drive in the bios that linux
(or at least lilo) may swap which drives it considers to be hda and hdc.
You can control this in lilo.conf by using the disk= / bios= options to
force lilo to use a particular mapping of hda and hdc onto bios drive
numbers.

As far as lilo is concernced, when telling it to install into an mbr, you
should tell it to install onto a physical drive, i.e. hda or hdc.  You
should not tell it to install onto an md device, since an md device is not
actually a drive and doesn't have an mbr.  Also, since lilo isn't aware of
raid, you shouldn't tell it to use an md partitiion as a boot partition.
Just tell it to use the corresponding physical partition, i.e. hda0 or hdc0
or whatever.  Since all lilo needs to do is map the location of the kernel
on the disk, it is happy with the physical partition.  Also, the boot
partition should be an ext2 partition.  When you mount your boot partition
after the kernel has started (typically via fstab) you can mount the md
partition at that point, and your modifications will be mirrored.

While you can get away with telling lilo to use the md devices for mbr and
boot partitions on a raid-1 mirror (since the two drives are just identical
copies of one another with a little extra information, the raid superblock,
along for the ride), this will not work for the other raid configurations
where the drives are not basically copies of one another, such as raid-5.
It is best to not get in the habit of telling lilo to use the md devices,
since it won't work in the general case.

So far the raid support has always handled single disk failures without a
hiccup for me.  The challenges start when you want to replace a failed
drive or have a multiple disk failure.

> So far I seem to be doing well, but what about the relationship between
> /etc/raidtab and the raid array itself?  Can I update the raidtab file
and
> change /dev/hda to be raid-disk 0?  What tool causes the RAID system to
> re-read the raidtab file and implement the changes?  Does it matter?

Once the raid devices have been created the kernel md code does not look at
the raidtab file; it only looks at the raid superblocks.  As near as I can
tell, only the utility programs (such as mkraid and raidhotadd) look at the
raidtab file.

You can edit the raidtab to add additional raid devices, but I wouldn't
recommend making any changes to the configuration of existing devices.
There might be some cases that would work, such as adding a spare disk to
an existing device, but in general I think you're asking for trouble and
risking data loss if you make changes to an existing device.

You can move physical drives around (as far as which ide channel they are
on) without having to make any changes to raidtab or even tell the kernel
what you have done.  The kernel md code figures out which drive is where
based on the info in the raid superblocks.

mkraid and raidhotadd/raidstart are the main programs for creating and
modifying md devices.

> And more importantly, what about re-installs on a system on which RAID is
> currently setup?  Case and point - Now that I have the desired partitions
up
> and RAIDed, I am going to do a REAL install of my system.  When I reboot
> into the installation will I be able to just mount the /dev/md0
partition?
> I'm going to take along my current /etc/raidtab just to be sure, but I
hope
> I don't have to re-mkraid my partitions.

I have found the install-time support for creating and installing into raid
devices to be spotty at best, and it varies widely from one distribution to
another.  I used to run RedHat but switched to Mandrake when I wanted to go
to raid because RedHat did not support creating and installing into raid
devices at install time at all, and Mandrake did.  I was forced to switch
off of Mandrake when they started using gcc 2.96 and switched to SuSE which
still had 2.95.  SuSE does not support installing into raid devices at all,
so I had to learn how to do it manually.

The one surefire manual approach that will always work is to do a non-raid
install onto a separate spare disk, boot that non-raid system, then create
your raid devices on your other disks, copy everything over from the
non-raid spare disk to the raid devices, modify the various details of the
configuration that matter (kernel boot device, lilo, fstab), maybe build a
new kernel with proper raid and filesystem support (depending on your
distribution), and finally remove the separate spare disk and boot off the
raid devices.  Done properly, this will always work, assuming you have an
extra ide channel to support the spare disk!  If necessary, you can
temporarily remove your cd-rom and put the spare disk on that channel.

As near as I can tell, Mandrake still has the best install-time raid
support.  If you have separated your system and data partitions, you can do
a new install into your system raid paritions, and it does work and is
fairly painless.  Of course, it is always best to make backups of anything
you care about first.

Dan Carlson