I been experimenting with software RAID1 under 6.1 on a test server, and
here's some interesting things I've come across:
The test server in question is IDE only, with the drives configured as follows:
primary boot disk - ide0, /dev/hda
secondary boot disk - ide1, /dev/hdc
I'm not sure how my experiments would turn out on a SCSI box, so take what
you read with a grain of salt and remember - YMMV. ;-)
First off, it is possible to RAID1 the boot disk, including / and /boot
under 6.1. This turns out to be somewhat of a bad plan, at least on my
test server. I wanted to know what would happen if one of the drives died
and the server had to be rebooted.
If the secondary drive fails booting from the primary drive is
straightforward - it boots as normal but detects the secondary drive has
failed and runs in degraded mode. After shutting down the server and
plugging the secondary drive back in, re-adding the second drive to the
raid mirror was pretty easy - 'raidhotadd [md device] [device to be added]'.
If the primary drive fails, booting from the secondary is a little more
problematic. Since LILO doesn't get installed on the MBR of the secondary
drive a boot floppy is necessary, which further complicates matters. The
boot floppy wants to make root /dev/md0, but it is unable to read the /boot
directory and fails. Oops, slight problem! Unfortunately, trying to
pre-install LILO to the MBR of the secondary drive seems to be a chicken &
the egg problem. In order to install LILO, I need to be able to boot from
that drive and in order to boot from that drive I need LILO installed. If
their is a way to tell LILO to install to the MBR of a different drive,
could someone enlighten me?
The only way I've been able to boot from the secondary drive is to put
/boot on a separate partition that isn't RAID'ed. Then you can make a boot
disk that works. It still wants to make root /dev/md0, but since /boot is
on a non-RAIDed partition, it's able to read it and load the kernel and/or
RAID modules.
Given the following issues:
1) The complexity of booting from the secondary drive.
2) Having to locate /boot on a non-RAID'ed partition in order for a boot
floppy to work and having to keep the copies of /boot on both drives in sync.
3) The likelihood that a serious disk failure will cause the server to
crash thereby necessitating a reboot.
4) The simple fact the most disk drives are much more reliable than they
used to be.
I'm inclined to do the following:
1) RAID important filesystems like /home and filesystems that change
frequently like /var.
2) Leave the rest of the mostly static filesystems on regular ext2 partitions.
3) Continue to use cron to run my rsync script that keeps non-RAID'ed
filesystems up to date.
This makes it pretty simple to boot from either drive, especially on my
server that has front-facing hot swap drives. It also preserves disk drive
order which means /etc/fstab is still pretty much current, even when one of
the boot disks has failed. Shut the server down, take out the bad boot
disk, move the secondary boot disk to that slot and reboot. Sometimes it
is necessary for me to boot from a floppy and run lilo to update the MBR on
the secondary boot disk. If I haven't made any changes to /etc/lilo.conf
since the last update then it generally isn't necessary to boot from the
floppy first.
One of my production servers is full SCSI and I could move the secondary
drive to SCSI ID 1 on scsi0 and it would probably boot without the primary
as SCSI ID 0, but that would mess up my drive order if the primary disk
failed and I'd have to change /etc/fstab. Currently the secondary disk is
on scsi1 at the end of the chain so if it's not installed it doesn't mess
up the disk device order.
Hope this gives everyone some insight, or at least some food for
thought. If someone has a better idea or thinks I'm way off base, please
let me know.
-Eric
Eric Sisler
Library Computer Technician
Westminster Public Library
Westminster, CO, USA
[EMAIL PROTECTED]
Linux - don't fear the Penguin.
Want to know what we use Linux for?
Visit http://gromit.westminster.lib.co.us/linux
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
