Re: ATA Raid

• Previous message: Chris A Czerwinski: "Re: KDE 3.2 - No Panel"
• In reply to: Bill Gradwohl: "RE: ATA Raid"
• Next in thread: Bill Gradwohl: "RE: ATA Raid"
• Reply: Bill Gradwohl: "RE: ATA Raid"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: fedora-list@redhat.com
Date: Wed, 4 Feb 2004 11:24:10 -0500

On Wed, Feb 04, 2004 at 09:38:49AM -0600, Bill Gradwohl wrote:
> I find it difficult to trust "software" RAID from past experience on
> other O/S platforms,

Don't blame Linux for the sins of other OSs.

> and [I don't trust software raid] from the purely logical
> perspective.

Why not? When the system wants to read it asks the disk that appears
positioned closest to the desired data, and when the system wants to
write it issues overlapping writes to each of the controllers with
raid disks. Fast and conceptually simple.

I once had a disk die in the middle of burning a CD, and I never
noticed a thing was wrong until the next morning when I got an e-mail
telling me I lost a disk. (This was RH 7.2, I had set up a cron task
to watch for changes in /proc/mdstat, and then send me e-mail if it
found any.)

Linux software raid 1 is even bootable--though getting your BIOS to
try more booting from than one disk might be tricky: but always be
careful about attempting remote reboots of degraded machines.

> not as good as "real" RAID.

One key point of raid 1 is reliability, and reliability likes
simplicity and eliminating single points of failure--and getting
things back up and running quick when they do fail. If you do
software raid 1 and something goes wrong, all your parts can be
inexpensive, generic, and readily available. In fact they can be
cheap enough to keep spares on hand. If, instead, you buy a "real"
hardware raid controller you now have an expensive, specialized, and
rare item--the raid controller--which has complexity and can itself
fail. Then what happens? Do you have another in stock as a spare?
Do you expect your local Microcenter to have a replacement in stock?

Certainly hardware raid has its place, but probably only if you have
redundant machines and you can seamlessly ride out the week or two it
might take to replace any specific spare. And by then you are
probably doing SCSI or fiber channel disks anyway; I don't pretend
that what I am saying applies in that region of larger installations.

> Software RAID is corruptible by definition.

By that token all "software is corruptable by definition", isn't it?
Are you going to quit running any software? I am far more afraid of
disks that might not flush written data all the way out to the platter
than I am of the Linux raid code misbehaving.

Finally, when comparing "hardware" to "software" remember that these
days nearly all "hardware" of significant complexity actually includes
a CPU, RAM, and software in some sort of ROM. The software in Linux
raid code is very well tested by now--will that be true of the
embedded software in your "hardware" controller? You also presumably
have a procedure for keeping your Linux code up to date--will you have
as good a way to keep track of any updates for you raid firmware?
Will needed firmware updates be as promptly released?

-kb, the Kent whose /dev/hda and /dev/hdc raid disks are not world
readable nor writable.

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

• Previous message: Chris A Czerwinski: "Re: KDE 3.2 - No Panel"
• In reply to: Bill Gradwohl: "RE: ATA Raid"
• Next in thread: Bill Gradwohl: "RE: ATA Raid"
• Reply: Bill Gradwohl: "RE: ATA Raid"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]