SOFTWARE-RAID-TIPS (was: Adaptec 7890 and RAID portIII RAID controller Linux Support)

[Carlos Carvalho]

Sorry for talking about this only a month later, I'm trying to catch
up with this list :-(

Doug Ledford (dledford at redhat.com) wrote on 25 February 1999 12:05:
 >Here are some design issues that I keep in
 >mind (some of these seem obvious, but I'm listing them anyway
 >because I've seen them done and I'm going to save this for future
 >reference as a start to a SOFTWARE-RAID-TIPS document that someone
 >else can expand upon and fill out better later).

A very interesting posting, as others have said :-)

 >2. Only put one RAID partition on any drive, and don't put any other commonly
 >used filesystems on there with it.  When you use a drive for RAID, make sure
 >it's dedicated to that purpose.  One of the key benefits of using software
 >RAID striped across 6 disks is the increased seeks per second that you can
 >get.  When you use 6 disks, you can get 6 times as many seeks under good
 >conditions.  When you make two raid arrays, one using the first half of all
 >six disks and the second using the back half of all six disks, you hurt
 >performance *more* than you would by making one big array and just using it. 
 >Part of the reason for this is that if you had one big array, then all the
 >files on that array may be residing in the first portion of the disks.  To
 >seek from any one file to another could be a relatively short seek.  When you
 >split the filesystems, then a read of a file on each filesystem will
 >result in a half disk seek to get from one filesystem to another.
 >These half disk seeks will *destroy* your overall effective performance.

OUCH!! This is VERY BAD news indeed :-( What you recommend is
virtually impossible. If you have several partitions to put in the
raid it'll cause an unacceptable loss of space... If you have to put
/, /usr, /var and /home in the raid, how many disks will you need?

My option is to spread each partition on as many disks as possible,
using raid5. This maximizes space, and is also good for speed if you
use a small chunck size so that most operations are spread through
several disks that are accessed simultaneously. 

 >3. In my case, I've created a RAID array that's used as my /
 >partition, so I had to have 
 >a stand-alone /boot partition to store the kernel in. Anyone who
 >attempts to do this exact setup, I *strongly* recommend that the
 >/boot partition be at least 100MByte in size and that you actually
 >install a minimal installation on the /boot partition (as a bare
 >minimum, copy the /etc /bin /sbin /lib directories onto the /boot
 >partition, but in my case, I've also selected certain stuff from
 >/usr/bin /usr/lib and other directories to go over there as well).
 >This way, if anything does happen to your raid array, you have the
 >raidtools installed on your /boot partition, you can boot the kernel
 >with the root= command line switch, boot into a working rescue set,
 >then fix the raid array from there. It's much faster and easier than
 >rescue disks and since you have to have this partition for LILO
 >anyway, you might as well make effective use of it :)

This is a minor point, but I don't think this is useful with the
current versions of the code. If you manage to load the kernel, it'll
do everything for you, even if the array is out of sync, disk numbers
have changed, etc. So all you have to do is load the kernel. I think a
small partition containing just lilo and the kernel is enough. If this
disk fails you can use a floppy with syslinux and the machine is back.
This may need manual intervention, but if the boot disk fails the
machine won't boot automatically anyway.

What if the raid partitions don't work even with the kernel loaded?
Then you're lost, and all the software listed above won't help you. If
the kernel can't start the partitions, nothing will do it. You have to
re-install from backup if you use raid5. With raid1 you can mount the
partition directly, so you don't need all the stuff on the boot one.

I'll redo the raid here to include one more disk, and in the new
partition scheme I won't even copy the boot partition in more than one
disk. I'll use Doug's idea of using the other disks for swap.

I agree with the other points.


To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message