Slashdot Mirror
Managing RAID on Linux
A person deciding to go with RAID faces a panoply of options and gotchas. Hardware or software? How many controllers? ATA or SCSI (or ataraid)? RAID 1 or RAID 5? Which file system or distribution? Kernel options? Mdadm or raidtools? /swap or /boot on raid? Hybrid? Left or right symmetric? One poster pointed out that putting two ATA drives on the same controller could impact performance. Yikes! Didn't I do that? Upon discovering that O'Reilly had just published its Managing RAID on Linux book, looking at sample chapter , I bought the book and let my blood pressure return to normal.
RAID is one of these subjects that is really not complex; it's just very hard to find all the information in one place. This is precisely the book to solve the problem. Author Derek Vadala, sysadmin and founder of Azurance.com, an open source/security consulting firm, has gathered a lot of information and even personal anecdotes to go through the decision making process when going over to RAID. He goes step-by-step through that process, educating us about hard drives, controllers, and bottlenecks along the way. This exhaustive book may be the first to bring RAID to the masses.
Although parts of the book (RAID types, file system types) may seem already familiar to experienced Linux users, it is helpful nonetheless to have everything in a nifty little book. A section of file systems provided not only a rundown of the merits and drawbacks of each one, but also a guide to their utilities. I learned for example what "file tails" for Reiser are, and why using them causes performance to degrade after reaching 85% capacity. The book compares raidtools with mdadm as well as lovely commands like nohup mdadm -monitor -mail=paranoidsysadmin@home.com (which, if you haven't guessed, causes the system to email you RAID status reports upon boot).
People who use software RAID may skip over the chapter on RAID utilities for the leading RAID controller cards. Still, there was one interesting tidbit: Why, the author asks, do makers of controller cards put all their BIOS utilities on DOS floppies which require us to find a DOS boot disk? Seriously, how many of us carry around DOS boot disks nowadays? The book made me aware for the first time of freedos, an open source solution that solves precisely that problem.
The Software RAID stuff was pretty thorough and clarified a lot of things. The book does an excellent job in helping to identify and eliminate bottlenecks and optimizing hard drive performance (using hdparm and various monitoring commands). The anecdotes and case studies definitely clarified which RAID solution is suited for which task.
I am less impressed by the book's sections on disaster recovery and troubleshooting. Although these subjects are brought up at several places in the software RAID chapter, the book could have discussed several failure scenarios or used a fault tree (such as the famous Fault Tree in Chapter 9 of the Samba book, a marvel for any tech writer to read). The book doesn't even discuss booting with software RAID until the last 10 page of the book and then gives it only a single paragraph (even though the author acknowledges it as "one of the most frequently asked questions on the linux-raid mailing list."). Call me old-fashioned, but isn't the ability to boot into your RAID system ... kinda important? As someone who just spent a significant amount of time troubleshooting RAID booting problems in Gentoo, I for one would have liked more insight into the grub/lilo thing. Also, in the next paragraph in the last chapter on page 228, the author casually mentions that "all /boot and / partitions must be on a RAID-1." Say what? Please pity the poor newbie who religiously follows the instructions in the book but fails to read until the end. I'm not sure what the author meant by this statement, but it required a much more substantial explanation and needed to go into a much earlier chapter.
These complaints don't detract very much from this excellent book, a true O'Reilly classic and a model of clarity and helpfulness. This book provides enough knowledge to avoid the dread and uncertainty that comes with trying to tackle Linux RAID. With a book like this, a sysadmin can sleep a little easier.
Recommended Readings:- Reliable Linux , by Iaian Campbell, Wiley and Sons, Dec 2001, ISBN: 0471070408. Gives excellent information not only about RAID but on general Linux reliability issues.
- Software RAID in the Linux 2.4 Kernel by Daniel Robbins. (Part Two).
- Linux Journal Article on Software RAID by Joe Edwards, Audin Malmin and Ron Shaker. ( Part Two).
- "How to do a gentoo install on software RAID" by Chris Atwood. Gentoo User Forum.
Robert Nagle (aka Idiotprogrammer )is a Texas technical writer, trainer and Linux aficionado. You can purchase Managing RAID on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
but the easiest way I've found is to go with hardware RAID. It's easier to setup, doesn't put any extra load on the CPU, and only costs a few hundred dollars extra.
Mind you I'm thinking of RAID used in producion instead of someone RAIDing two drives in there home machine.
Then of course, everything would be easier if the hardware manufacturers also sent along a DOS bootdisk, perhaps with FreeDOS to avoid licensing fees.
...was the use of the word "panoply".
That word simply isn't used enough in the modern vernacular.
Okay, mod me down now...
"It's a tarp!" -- Dyslexic Admiral Ackbar
Is it possible to use Firewire and a service like Rendevous to make an intelligent redundant system? It's a thought at least. My firewire drive I use for my Inspiron works nicely enough. Would firewire be cheaper than RAID for servers, however?
Syr GameTab.com - Game Reviews Database
panoply
n. pl. panoplies
Looks like number one is most appropriate, although I've never referred to my arrays as "splendid".
never mind the difference between RAID 1 and 5! Maybe the maintainer should add such questions to the FAQ. After all everybody started once...
The performance hit is not worth the return.
For you, it's not. For someone else, it might be.
There are any number of situations where it might be appropriate to exchange some performance for increased data security. Just because you can't imagine them, doesn't mean they don't exist.
might not valid in a year or so.
... but some of the information is out of date, and the tricks suggested by people a year ago may be no longer needed today.
re:
this is something you are going to face when you are considering a technology that changes rapidly. a book on the subject isnt going to change the dynamic nature of linux.
-- john
"all /boot and / partitions must be on a RAID-1."
/boot must be RAID1, but / can most assuredly be RAID 5 (or, I presume, any of the other RAID levels). I have this running on an ol' RedHat 7.0 box:
/dev/md1 / ext2 defaults 1 1
/dev/md0 /boot ext2 defaults 1 2
/dev/md0 /dev/sdb1 /dev/sda1
/dev/md1 /dev/sda6 /dev/sdb6 /dev/sdc5
With raidtools, at least,
Hunk 'o fstab:
Similar hunk 'o raidtab
raiddev
raid-level 1
nr-raid-disks 2
chunk-size 64k
persistent-superblock 1
#nr-spare-disks 0
device
raid-disk 0
device
raid-disk 1
raiddev
raid-level 5
nr-raid-disks 3
chunk-size 64k
persistent-superblock 1
#nr-spare-disks 0
device
raid-disk 0
device
raid-disk 1
device
raid-disk 2
*Shrug* Wonder what the context of that quote was within the book?
the no
The learning curve on most Wintel software is on the order of the time needed to search through half a dozen menus to find the right command.
Trying to make everyone be an expert before they can operate their machine is how operating systems die.
Does this book talk about the md driver's
multipath personality?
This is the most poorly documented part of the
md driver.
if you read the raidtab man page ("man raidtab")
you will find _no_ mention of multipath whatsovever.
Yet, the md driver can do mulitpath (well, failover) if you set it up right.
It has limitations though... You can't install to multipath devices, or boot from them (lilo/grub, the various distributions installers don't understand md multipath) and, if an hba fails in such a way that interrupts are not generated...commands just go out to lunch... then md won't notice anything is wrong, and so won't failover. Also, it does nothing to notice if the failover path is actually working, so if that path fails you won't have any notice that redundancy is lost....
Well, multipath is not RAID, so maybe this book
doesn't cover it, but any book on software RAID for linux should probably cover all the features of the md driver.
I will be interested to see this book.
I've stepped away from the software RAID idea on my boxes, due to the availability of cheap hardware RAID, such as Promise's SX4000. It will do hardware RAID 5 for four+ drives and has a SDRAM slot for cache expansion. Coupled with LVM, it ended up being a good solution for me, as I had both the reliability, and good volume management if I wanted to combine arrays.
The problem I've had with the software RAID is reliability and expandability. It is a pain in the ass if you lose a drive in the array, and it is next to impossible to add a drive (other than a stand by drive) to your existing RAID 5 setup.
Aah, opinions...
------------------ D. A. Davenport: http://www.firebin.net
Software RAID, excepting mirroring a pair of drives, sucks. Period. The performance hit is not worth the return. Ever do stripping in software? Worse, RAID 5 in software? It sucks. You could spend a few $ and get hardware RAID and not only actually get better performance but not be concerned that some corruption in your OS that is managing that RAID will affect the data stored on it.
It sucks on your hardware. When you use fast SCSI disks and have fast CPU(s), software RAID is much faster then (very expensive) hardware RAID solutions. The chip on your hardware RAID card (usualy ARM) can't be faster than CPU.
Regarding trust, you should trust (open source) software RAID more than proprietary firmware.
Please pity the poor newbie who religiously follows the instructions in the book but fails to read until the end.
On the other hand, pity the newbie who cracks a book open and starts setting a server up page-by-page.
Several years ago I set up a RAID-5 with Win NT-4 Server. It worked well enough (there were only two users) until NT-4 tanked and I had to re-install the OS. [pffft!] No more RAID-5 array.
Yeah, there were Resource Kit hacks for getting it back, but it was a real pain.
Software mirroring with NT-4 was almost as tricky to recover from if the primary copy died. If the mirror died, though, it was a piece of cake.
You were 80% angel, 10% demon. The rest was hard to explain. - Over The Rhine
"Math in a song is good."-Linford
The availability of cheap and expensive raid solutions for linux as well as good documentation like this book will no doubt help linux and open source to gain more acceptance in the enterprise.
RAID level 01/10 is both expensive *and* pointless
Well, maybe for the average power user, but not the real power users. Pretty much every stock exchange, airline reservations system, credit card switching system in the world uses mirroring and striping. Operating systems such as HP's Non-Stop Kernel (from Tandem) and IBM's Transaction Processing Facility (TPF) work this way and run these mission critical systems.
Why? I/O throughput and redundancy in applications that can't afford to fail. The disks aren't expensive compared to the rest of the system and even less expensive than the downtime.
These aren't Linux systems, but as Linux scales up there will be times when it will necessarily copy from mainframe-class systems.
(From the raid howto)
4.7 The Persistent Superblock
Back in ``The Good Old Days'' (TM), the raidtools would read your /etc/raidtab file, and then initialize the array. However, this would require that the filesystem on which /etc/raidtab resided was mounted. This is unfortunate if you want to boot on a RAID.
Also, the old approach led to complications when mounting filesystems on RAID devices. They could not be put in the /etc/fstab file as usual, but would have to be mounted from the init-scripts.
The persistent superblocks solve these problems. When an array is initialized with the persistent-superblock option in the /etc/raidtab file, a special superblock is written in the beginning of all disks participating in the array. This allows the kernel to read the configuration of RAID devices directly from the disks involved, instead of reading from some configuration file that may not be available at all times.
You should however still maintain a consistent /etc/raidtab file, since you may need this file for later reconstruction of the array.
The persistent superblock is mandatory if you want auto-detection of your RAID devices upon system boot. This is described in the Autodetection section.
I beg to differ.
After having four hard drives die and losing various amounts of data, I purchased two 100GB drives and made 6 RAID1 partitions using about 90GB, and a 20GB RAID0 partition with the remainder.
The security of a number of RAID1 partitions for backup is a nice feeling to have since a drive failure can't wipe out my data now.
The RAID0 space is scratch space, so it doesn't matter if mtbf is reduced--there's nothing important permanently stored there.
You did realize that you don't have to have the entire drive use the same RAID level...
Windows software RAID (of any type) sucks, that doesn't necessarily apply to Solaris or Linux (in which I've used both, Solaris tends to be a little bit of overkill in many cases, but if you need it you need it).
/etc files (infact, the IBM EVMS stuff doesn't even use config files, it doesn't need them.. ) Just a few tips for the curious. (I use Gentoo, so I don't have to add these patches.)
As far as IDE channels, many many motherboards these days have about 4 ide channels (mine does, and it's not even NEW) 4 ide channels can make a good raid. My linux RAID 5 (software) is pretty transparent and read speeds are noticable faster. This is even MORE true if you put in the EVMS patches from IBM and use the GUI tools to create and manage RAIDS without even editing
Hardware RAID is marginally, not always better. For one thing, you are limited to the idea of RAID that you board manufacturer believes in.. It's not always what you need. CPU power? On any machine faster than 1ghz you never even notice. 2ghz and software RAID is invisible. Yes, software RAID sucks on windows (due to the stupidest fucking volume/RAID managing service I've ever used), but it's viable almost everywhere else.
Sometimes that extra few hundred dollars is an extra $20k (if you're doing lots of machines), if you can deal with the CPU hit is still more economical as long as it's reliable. Solaris/Linux RAID are ready for prime time, W2k's is still trying to figure it out. (For Windows boxes, please get hardware, save yourself headache.. thanks!)
Jan 26 04:15:02 hostname kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 26 04:15:02 hostname kernel: hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
I've looked all over the place for the answer, google, mailing list archives, Usenet, local Linux friends, etc. and haven't been able to find a definitive answer. It's like nobody really knows what that error messages really means.
Newsgroups suggested bad cables, so I replaced those (twice, once with brand new cables bought specifically for the purpose). Some info suggested the drive or the drive's controller was failing, so I replaced it. Other info pointed to my IDE controller, so I installed a new one dedicated only to the RAID pair. I saw info that said the raid tools were to blame, and to see if the errors go away when the mirror is broken. No dice. Other info I found suggested that it was the IDE drivers in the kernel and that the messages were nothing to worry about unless I was seeing data corruption. I'm not seeing corruption so I'm left with this option.
If the book can shed some light on the error message voodoo one sees with Linux's IDE driver, then I'll buy it. I'd pay double what they're asking, even.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I guess it's better to mirror across the channels as well (and my small tests seems to indicate that) but is it so?
Peder
While I'm certainly a proponent of "dead-tree" documentation, I have to take a moment to disagree with one of the statements made -- I'm sorry, but newsgroups, while perhaps containing out-of-date info, are (if it's a good newsgroup) capable of letting you know the current state-of-affairs. This is substantially -less- true with books. Case-in-point is Samba: it's *DARN* hard to know, from the Amazon description (or wherever) which Samba books describe the current state (2.4 and above) of Samba, whereas the FAQs, newsgroups, etc., are fairly obvious on it. Bottom line? I'll take a good book any day, but when in doubt, I'll go with current info gleaned off the newsgroups and other on-line resources.
Why, the author asks, do makers of controller cards put all their BIOS utilities on DOS floppies which require us to find a DOS boot disk? Seriously, how many of us carry around DOS boot disks nowadays?
Well, given Dell's recent announcements, I suppose fewer and fewer of us will be doing so.
But really, the author's point is so moot that it's embarassing: if it's my job to maintain a RAID array, and the utilities are on DOS floppies, of course I'm going to have access to a DOS boot disk. So what ? Just how hard is it to carry such a thing around, and why is this is a worthy thing to rail about, in a book about RAID ? If the author wastes too much time talking about stuff like this, this book can't be that useful - arggh, I've wasted too much of my own time already.
Ummm...Sir...you greatly misjudge the value of raid zero and I suggest you do more research before making any comments like this again. With the right drives, striped across two seperate IDE channels, there is a noticeable performance increase
Anonymous Cowards - Oh God, How I hate you
That's striping. Why am I even bothering posting this? Maybe if my class wasn't cancelled, you wouldn't have to read such a worthless post.
incripshin
But based on the fact that Hardware RAID for IDE drives has come down so much. I am not sure why you would use software.
Anonymous Cowards - Oh God, How I hate you
It's not that hard.
- Power down the computer
- Remove cover
- Blow out all dust and insect husks
- Spray in RAID
- put cover back on for 15 minutes.
- Remove cover again
- blow out insect husks.
Trolling is a art,
On a modern machine, software IDE RAID is still beneficial. For striped arrays, the performance penalty on the host CPU is very minimal compared to the device performance. Of course, hardware solutions are easier to set up. If you buy a 3Ware card, or something similar, kernel support is a non-issue. But for home users that just want software to load faster or wish to have backups, IDE RAID is a cheap solution that performs very well.
So, you say it sucks, I say it's fine. You say toe-mott-oh, I say toe-mate-oh. Hardware RAID is more than just a few $. It costs hundred(s) more than software RAID controllers. I've had software controllers that performed better than the current high-end SCSI drives at the time. I can attest to the fact that CPU load was a non-issue. Performance was excellent and was the most inexpensive way to gain speed. It's ideal for home users that aren't wanting to spend a fortune on limiting the swapfile chug.
So, please define "sucks". Enlighten us softRAID users on what the problem is. Or is the problem really that you've spent your fortune on some overpriced SCSI drives that get outperformed by a couple of ATA100s?
Grrr.
1) He already stated this fact. 40% I/O throughput increase. (actually quite a large variability, but it's a usable number)
2) Read the subject line! He said, "THE AVERAGE POWER USER..." Now I read that as meaning the home Linux geek/developer who likes messing with the guts of their system. Companies use RAID0 all the time, or more often RAID1+0. RAID5 is equally common, implemented in hardware. This is not what he's talking about. This is not the target of his comment.
Sigh. Sorry to rant, but every follow up to this article has neglected this point.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I once had to install chinese win95 and chinese ie and chinese office... and I dont speak chinese. I barely speak my native language of english......
I for one know one user who striped his IDE drives on a RedHat box, very happy man he now is. Achieving over 90Mb/s throughput compared to the normal measly 40Mb/s saves him a lot of time when working. Anything important is just backed up to his server. I myself spent much time trying to use hardware RAID on an Adaptec 1200A IDE controller but finally gave up and went software. I'm mirroring for safety and not for speed because I store at least a dozen linux iso's and all my .ogg files and it would REALLY suck to have that on only drive and watch it die. As a side note, it shouldn't matter what RAID level you use because real power users have more than one box. :)
pfft.. 40% increase in IO throughput, that is useless.
RAID 0 is pointless - gosh, I wish all the video editing studios out there knew this. They've been duped into believing 150 megs a second sustained has value. What morons.
Too bad cheap RAID5 cards don't exist. - Hmm, you mean like the Promise SX4000 that costs $150?
I'm Rick James with mod points biatch!
Pardon my flame but:
That's a really rude attitude towards other users. I'm glad that you realize that, and I'm sure your friends would be impressed by your vast knowledge of IDE RAID...if you hadn't driven them away by beating them about the head with it in the first place.
The attitude of answering all questions with "You don't want to do that: it's stupid, and you're stupid for thinking about it" is utterly counter-productive to the business of an open forum like Slashdot. If that's your opinion, then you're welcome to it, but you don't impress the rest of us by airing it (poorly, I might add). Without any facts to back your opinion up, you leave the rest of us wondering if the performance problems you've encountered were due to your own inability (stupidity you might say) to configure software RAID efficiently.
credo quia absurdum
No matter how fast your CPU is, you aren't going to beat a dedicated hardware RAID controller. Also, if you're going to spend the money for SCSI, why wouldn't you spend a little more and go with a hardware solution? That's like buying a BMW then "saving money" by adding the fog lights yourself.
A better title for the book would be...
RTFM: RAID - The F*cking Manual!
I recently installed raid out of the how-to and other information I googled for. I really did not have much problem with it. I took a basic configuration and then started playing with it to make it work the way I wanted. Seemed pretty intitive compaired to many other things out there to configure. As for why to use Software Raid? I had an old box lieing around with no HW raid but needed a non-production server as a sandbox, bingo I had one. This turned out to be a really good idea because soon after I built it one of the disks went bad and I was albe to save all my work.
Hmm, I get rather good performance from my IDE software RAID-5. As far as I can tell, reading from the buffers pretty much maxes out the PCI bus and I also get good performance for actual platter reads. Here are some quick numbers:
(granted this is not an exhaustive benchmark)
Not spectacular, but certainly more than fast enough for my media server. Also probably better than I could do on a 68-pin Ultra Wide SCSI bus, even with multiple drives.
Enigma
Perhaps what we need is more penetration of Linux into business settings, so people can buy books with their employers' money?
--------------------
Escape geekdom! I did.
Link: Root raid 1 on Debian.
Nuff said.
With disk drives steadily increasing in size, and backup options not keeping pace, everyone has a use for RAID 1. Frankly an extra 100 bucks on another drive is well worth it in comparison to the hassle of maintaining an ongoing backup process. I don't really care that I'm "wasting" a whole drive, since it's still going to be a ton cheaper than any RAID 5 solution.
Ever ripped 500 CDs to MP3 format?
Ever done it twice?
I have, and never will again if I can help it...go RAID 1 go!
That onboard Promise RAID controller you dished out the extra $50 for on that new motherboard is not going to get you a nice hardware RAID 5. AFAIK they can only do 1,0, 0+1, or 1+0. Also, I see people whining about software RAID as compared to hardware RAID. Running a striped set through software was nearly unfeasable a few years ago, but with the resources new machines have these days, the difference is almost negligable, as long as it doesn't have to fight for system resources. let's not forget software RAID is alot cheaper than buying a RAID controller.
At any rate, taking the view that hardware RAID is always the solution and software RAID is never the solution is just bad sysadministration.
Everyone is entitled to their own opinion. It's just that yours is stupid.
Up until now I've bought only SCSI drives because heavy compiles (which I do a lot) just choke IDE down. I now have a 4 x 60 GB RAID-1 and it just screams. With a one time investment in a proper IDE RAID card with escalator scheduling, tagged queueing and big cache I still save a lot of money by being able to buy large but cheap IDE disks.
You must be from america. Land of the Lazy, Home of the apathetic. go to your damn class.
the poster obviously doesn't know what he's talking about.
a 'rubbish' 500Mhz CPU - 500,000,000 ops / sec
a 5ms access time SCSI HDD - 200 ops / sec.
so what if the CPU on the RAID card is a pathetic 100MHz job, it'll still be able to keep up with the data flow from the HDD, even when that data is being burst through.
How much cache ram have you got on that RAID card is a better indication of performance improvements for your hardware.
And why would I buy this book or any book on RAID if I am going to use a hardware solution. If I have hardware then I am going to just make sure it has support & instructions for Linux and be done with it.
Exactly. If it is just a storage device, with relibility and stability a priority, software RAID could be a great option. The CPU is sitting twiddling its thumbs even under heavy loads, even if you throw in two 64bit PCI Gigabit Etherenet cards for data. Considering a three year old 500MHz Pentium III is a hand-me-down these days, your CPU will still be underutilized.
I think books like these should be topical oriented rather tha OS oriented.
Or am I asking too much?
Do explain what *exactly* is wrong with Window's software raid features. Besides being made by your favourite company, Microsoft, that is.
another 'biased-to-the-point-of-bigotry' post.
I get >160 Megabytes per second off my software striped drives, which is far faster than I've ever gotten off any hardware RAID.
And I've found the RAID 5 overhead is nominal, and very reliable.
Ever do stripping in software?
Yes. Back in the early 1990s I downloaded an EGA strip poker game. Software stripping was just not as good as the real thing.
If we're so damn lazy why do I get up and go to work for more than 40 hours a week while you pansy euros get your 36 hour weeks?
No matter how fast your CPU is, you aren't going to beat a dedicated hardware RAID controller. Also, if you're going to spend the money for SCSI, why wouldn't you spend a little more and go with a hardware solution? That's like buying a BMW then "saving money" by adding the fog lights yourself.
You are going to beat hardware controller, because the chip running your software RAID (P4 Xeon, 2GHz) is much faster than the chip on the hardware controller (arm, 100MHz). Your only limitation is the IO bandwidth, thats why you go with SCSI.
Server manufacturers sell hardware RAID as expensive add-on, but they are not advertising any benchmarks showing speed advantage. Because there is none. Current controllers are just not good enough, can't keep up with speed advances of CPUs.
1 My first thought was, he lied in every word,
2 That hoary cripple, with malicious eye
3 Askance to watch the working of his lie
4 On mine, and mouth scarce able to afford
5 Suppression of the glee that pursed and scored
6 Its edge, at one more victim gained thereby.
7 What else should he be set for, with his staff?
8 What, save to waylay with his lies, ensnare
9 All travellers who might find him posted there,
10 And ask the road? I guessed what skull-like laugh
11 Would break, what crutch 'gin write my epitaph
12 For pastime in the dusty thoroughfare,
13 If at his counsel I should turn aside
14 Into that ominous tract which, all agree,
15 Hides the Dark Tower. Yet acquiescingly
16 I did turn as he pointed: neither pride
17 Nor hope rekindling at the end descried,
18 So much as gladness that some end might be.
That's 10 pages about "booting" to software RAID. Not the same thing.
People who disagree with you are not automatically evil, greedy, or stupid.
I don't know what this writer is complaining about. Software RAID on linux is REALLY easily implementable from the FAQ. And secondly, the RAID mailing list (easily searchable) is filled with answers to all sorts of problems. And thirdly, Neil Brown, who wrote much of the kernel RAID software, is on the list and has always been very helpful. Three cheers for Neil!
The original story sounds like someone who is trying to sell his book.
1/ Linux can rebuild RAID from on-disk information. NT 4 is deficient in this regard, it would seem.
2/ Problem is worse with hardware RAID, because if I lose the card, I'm fucked. I either have to have spares, or wait on a controller. Never mind what happens if the manufacturer goes out of business.
When I decided to set up a RAID under Linux, I recalled seeing an icon in my webmin. I used Webmin almost exclusively in setting up the RAID. I didn't need any HOWTOs in the process of setting up this thing.
So while there are good collections of information out there, there are also very good tools out there with which to accomplish useful tasks.
I think it's precisely that HOWTOs are rarely if ever needed with Windows stuff that it still has an edge over Linux where the masses are concerned. So it's nice that HOWTOs are out there, I think it's more important that good tools are out there that are easy and self explanatory.
This guy really like to review books.
Tuus crepidae innexilis sunt.
I think that a better title for this book would be,
RTFM: RAID - The Fucking Manual.
Life is the leading cause of death in America.
EVMS is IBM's version of RAID for linux. This is natively available on gentoo linux. I've been running it on a few boxes with great success. The utilities make it a lot easier to set up raid, lvm, etc.. Definately worth looking at for those interested.
I'm not a real doctor, but I recommend beer.
This post brings up an interesting topic. I too have found may how-to's and online resources available to be outdated. Has anyone setup some sort of Linux HOW-TO/Help Desk WIKI where information can be continually updated by the community? If not, I would be interested in hosting something like this personally. Input appreciated.
-Anonymous Coward
Sorry, but there are some things to be taken into account here.
:)
First of all, some of today's controllers (such as the HSGs or HP Smart Arrays) are running on pretty good RISC chips. Moreover, they have good amounts of memory to use as read ahead or writeback cache, which do speed up I/O instead of sharing memory with the OS.
About the speed of the controller's processor as compared to the main processor, just remember that, in today's standards, one SCSI channel could only work at 160MB/s, and, even if we needed one processor cycle for each byte to be read/written (we don't), we would only need a 160MHz processor to do the job.
Well, come think about it, processors embedded in today's modern RAID controllers usually have a 64-bit data bus. This means that any transaction is 8 bytes long. Being the worst case in performance a RAID-5 write (which involves 4 I/O operations) we still get an average of 2 bytes per processor cycle.
That's why RAID controllers don't come with fantastic processors -- there's simply no need to.
We could also think of availability, but that would be another long issue, and hardware RAID wins almost in all cases (except for controller multiplexing), but the best reason you would have to think about software raid would be the cost.
I could be wrong, though
Hey - just say "Windows mumble Sucks!" and it's worth 2 mods around here.
He did mention the volume management, but failed to say if he was talking about NT4 or NT5 (which uses a version of the veritas stuff in his fav Solaris).
I've never had a problem with NT RAID, but you'd better understand the recovery stuff before you need to. I imagine that's true everywhere.
Ultra SCSI is so 1997. FWIW, I get ~38 MB/sec reads off a single U2W patter, so I don't think your numbers are all that great.
All I want is a software RAID 5 array that I can use in both Windows AND Linux. Maybe it's possible. I dunno. I've never found any instructions.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
> RAID level 1 is just a bit-for-bit backup system,
That's exactly why it's good. It also increases your read speed by getting data from both drives.
> and wastes 1/2 your disk capacity.
I don't consider a backup to be a "waste". One extra hard drive is MUCH cheaper than your TIME, and it will take a LOT of time to deal with all the data you could lose if your single drive fails.
My software RAID-1 rebuilds at 48M/sec, automatically, which is a lot faster than feeding in a stack o' CD-Rs, and cheaper than a bunch of DVD-Rs.
(RAID won't protect against data corruption or accidental deletion, however -- you will just get mirrored corruption! So you need an additional backup strategy as well, just like always. Except the relatively common PC drive death won't bother you. I have seen a lot of people's drives fail over the years.)
I'm sorry, but I have to strongly disagree with that statement. Processors in hosts have certainly sped up in the past few years, but few of them will provide the same level of throughput as a dedicated HW RAID controller. The reasons?
1, The host CPU has to run the O/S as well as the applications as well as manage the disks. This is a significant overhead.
2, The HW controllers have dedicated ASIC's which not only offload the work from the CPU's but are also tuned specifically for that purpose. Much like using a GPU in a desktop for faster graphics.
3, The HW RAID solutions will have a very tight, high performance O/S on board without all the cruft of a general purpose one.
No tests that I have done with storage (and I have done plenty) have never shown software RAID to be faster. Mind you, this is with large expensive cabinets attached to mainly big iron systems. Your milage may vary on the desktop.
At the end of day, I want the host to be spending all of its CPU cycles running an application, not having to manage peripherals too. The HW RAID controllers allow you to offload that work to a subsystem that is designed specifically for that purpose.
...but I'm not sure how well it works with RAID arrays. The softly-softly approach may be fine with individual disks, but if you have to manage a small army of them then discipline and the threat of violence is the way to go. Just let them overhear you muttering something about magnets and they'll soon get their act together. If necessary, format one as an example to the others. They're a bit like kids really.
Modest doubt is called the beacon of the wise. - William Shakespeare
Granted it's on Windows 2000, but I just ordered a SIIG PCI IDE RAID controller and 3 30 gig IBM drives. Total cost: ~$250 or so. The PC runs tape backups for a small workgroup, and we just needed the extra insurance of having a pair of RAID 1 disks plus a spare. The simple SIIG controller can boot from the RAID disks and we don't need online-restores or hot swaps or the like.
Software RAID is plenty good enough in the right situation.
As far as IDE channels, many many motherboards these days have about 4 ide channels (mine does, and it's not even NEW) 4 ide channels can make a good raid.
Isn't that just 4 IDE plugs, but only really 2 IDE channels? RAID embedded in your motherboard is usually of the Promise variety and cheap hardware raid isn't much better than software raid. Tom's hardware has an informative article on the difference between hardware and software RAID and they reported that this is the case.
Server manufacturers sell hardware RAID as expensive add-on, but they are not advertising any benchmarks showing speed advantage. Because there is none. Current controllers are just not good enough, can't keep up with speed advances of CPUs.
The main selling point for RAID on a server (at least for me) is ease of management. When you have something as basic as your drives, you'd rather not worry about driver incompatibility, problems with upgrades or anything like that. Just address the sucker as sda and be done with it.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
a 5ms access time SCSI HDD - 200 ops / sec.
care to back that up? Sure, if you send the drive out to get random sectors and disable reordering, that will happen, but it doesn't work like that. You frequently get contiguous chunks of a MB or more, which don't suffer from the 5ms access time. How did you think SCSI disks hit 40MB/s sustained, anyway?
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
You actually feel good about the Linux drivers that Promise gives you with the SX4000? I bought this card, and I wished I stayed away from it.
I am using it with four 120gb IDE drives with 8mb cache. For starters, if you use anything but the sxcslapp program in Linux to configure the drive, your drives are corrupt. All of 'em. And, your bios will return corrupt information regarding them. This causes DOS not to boot (hard freeze), and Linux to produce keyboard smashings on boot. This is a known firmware problem, and I'll be damned if they have any flashes available, even though the card is four months old. I just checked before writing this review.
Once I figured out that all the work had to be done with sxcslapp in Linux, I started building my RAID5, albeit with caution. Things here went pretty well, except a) performance sucked about as bad as a single drive and b) the closed source drivers rebuild the raid array with no warning if a drive fails and is replaced, even if the file system is mounted. So, this means that if you have a drive that bombs and you replace it, anything you write to the raid array will be wiped out. I could have used some notification.
The Linux drivers are horrible. They are written in 'Engrish', and the documentation might as well have been written by someone who doesn't understand computers. "Select the remove drive from array option to remove a drive from array". This continues for all of the options in their menu-driven app.
I am also forced to use Red Hat 7.3 for this. Great. I now have a cluster of Debian 3 servers I administrate and one Red Hat server.
I would have returned the card if my reseller would have taken my money. It's about equally expensive to buy IDE add-on cards, or maybe a bit less, and the software RAID in Linux seems to be firmly documented. I've used RAID1 in software on servers before, and it works nicely.
hdparm -tT /dev/sda
/old/usr/dpt/dptutil -L all
/dev/sda:
Timing buffer-cache reads: 128 MB in 1.55 seconds = 82.58 MB/sec
Timing buffered disk reads: 64 MB in 3.03 seconds = 21.12 MB/sec
That's on a 5-drive HW RAID5 SCSI UW2 array... on a P2/233:
#
DPTUTIL Version: 3.14 Date: 3/12/2001 LINUX CLI Configuration Utility
DPT ENGINE Version: 3.14 Date: 3/12/2001 Adaptec LINUX SCSI Engine
# b0 b1 b2 Controller Cache FW NVRAM Serial Status
d0 -- -- DPT PM2654U2 16MB 3013 DPT V1.0 1B-001280 Optimal
Physical View
Address Type Manufacturer/Model Capacity Status
d0b0t1d0 Disk Drive (DASD) WDIGTL WDE9180 ULTRA2 8726MB Optimal
d0b0t2d0 Disk Drive (DASD) QUANTUM ATLAS_V__9_SCA 8754MB Optimal
d0b0t3d0 Disk Drive (DASD) QUANTUM ATLAS10K2-TY092J 8758MB Optimal
d0b0t4d0 Disk Drive (DASD) UNISYS 006904ST39173LC 8686MB Optimal
d0b0t5d0 Disk Drive (DASD) UNISYS 006904ST39173LC 8686MB Optimal
d0b0t6d0 Disk Drive (DASD) WDIGTL WDE9180 ULTRA2 8727MB Optimal
d0b1t1d0 Tape Drive HP C1557A ----- Optimal
d0b1t1d1 Jukebox HP C1557A ----- Optimal
Address Capacity
d0b0t6d0 8727MB Hot Spare
Address Max Speed Actual Rate / Width
d0b0t1d0 Ultra2 80 MB/sec wide
d0b0t2d0 Ultra2 80 MB/sec wide
d0b0t3d0 Ultra2 80 MB/sec wide
d0b0t4d0 Ultra2 80 MB/sec wide
d0b0t5d0 Ultra2 80 MB/sec wide
d0b0t6d0 Ultra2 80 MB/sec wide
d0b1t1d1 Ultra2 67 MB/sec narrow
d0b1t1d0 Ultra2 10 MB/sec narrow
d0b1t1d1 Ultra2 10 MB/sec narrow
# Controller Cache FW NVRAM BIOS SMOR Serial
d0 DPT PM2654U2 16MB 3013 DPT V1.0 1.2A 1.10/15I 1B-001280
Address Manufacturer/Model FW Serial 123456789012
d0b0t1d0 WDIGTL WDE9180 ULTRA2 1.30 WT7050494021 -XXXX--XXO--
d0b0t2d0 QUANTUM ATLAS_V__9_SCA 0230 149023951887 -XXXX---XOX-
d0b0t3d0 QUANTUM ATLAS10K2-TY092J DDD6 169028940164 -XXXX---XOX-
d0b0t4d0 UNISYS 006904ST39173LC 6616 LMK413050000191900TH -XXXX--XXO--
d0b0t5d0 UNISYS 006904ST39173LC 6616 LMB4300700001929H2DQ -XXXX--XXO--
d0b0t6d0 WDIGTL WDE9180 ULTRA2 1.30 WT7050645361 -XXXX--XXO--
d0b1t1d0 HP C1557A U709 ------- --XX---X-O--
d0b1t1d1 HP C1557A U709 ------- --XX---X-O--
Capabilities Map: Column 1 = Soft Reset
Column 2 = Cmd Queuing
Column 3 = Linked Cmds
Column 4 = Synchronous
Column 5 = Wide 16
Column 6 = Wide 32
Column 7 = Relative Addr
Column 8 = SCSI II
Column 9 = S.M.A.R.T.
Column 0 = SCAM
Column 1 = SCSI-3
Column 2 = SAF-TE
X = Capability Exists, - = Capability does not exist, O = Not Supported
3-4 years ago, when we decided to use hardware RAID on our Linux servers, we bought some DPT Smartraid V hardware RAID controllers. Unfortunatly DPT was bought by Adaptec some time after. Adaptec has been really good at getting the driver included in the kernel, but the takeover seemed to delay this proces, so the time in between was a rough ride.
The lesson learned was, never have a production Linux system with (binary) drivers tied to a specific kernel or distro version.
That said, we have been very happy with the controllers, and since at least two disks has died without warning, the expense has easely been worth it. Our systems are used 24/7/365, so every minute of downtime annoys somebody. RAID really makes me sleep better, restoring a server from a slow tapestreamer, at some ungodly hour, while people nervously checks in, asking when we will be up again, is something I really want to avoid too much of.
YMMV, but I think hardware RAID still has an edge over software raid, mostly because I find it simpler to maintain in the long run.
If you are into LVM's, FS tools, and software RAID, go to:
http://evms.sourceforge.net/
and _drool_. Future stuff for now on production servers, but nevertheless.
Tons of Dell's with the PERC (aacraid/megaraid) controllers.
The nice thing about hardware raid is other than the driver for the scsi card, the OS thinks there is just one drive sitting there. No configuration on the OS side.
Also, RAID is going before the OS even starts booting. If a disk dies, so what.
Please correct me if I'm wrong, but if you have software raid and the disk the os/boot/raidconfig files are on goes, you have a dead box.
I'm adding my vote for 3ware. You can get an 8 port IDE card for less than $400 or an 8 port SATA card for under $500. Beware big IDE raids, cabling issues become a major pain. We ended up using 36" (out of spec) rounded ide cables for our last 1.1 TB raid. I'm hoping that next time, we can use serial ata disks and the forthcoming 3ware raid card with native SATA. Their current offering uses the same chips as the 7500 IDE raid controller, combined with SATA bridges.
Do you really need hardware raid? These days disks are so big that you don't need RAID5 (and thus a beefy raid controller) unless you need an unholy amount of storage. For redunancy, RAID1 will do nicely, either in software or cheap hardware.
Many boards now have 4 IDE channels, I.E. they support 8 drives.
Hun, I though if you have a RAID 1 mirroring software array running on linux, linux is smart enough to access different files from different drives. Muliple readers is something hardware raid can not do unless they have a special driver, and the os supports it. Writes take twice as long though.
I use a software RAID 1 mirror array on a squid proxy cache box. I would guess that the multiple readers on different drives would increase the throuput for a web caching proxy server since web pages have so many little files.
You know, the problem with RAID is that people tend to make general statements based on their own personal observation. You get a lot of "Software RAID sucks because it's slow" statements, and you also get things like "RAID 5 sucks", or "RAID 5 r0x0rz!"
The thing to keep in mind is that these things are very subjective based on what your application is. Let's take for example RAID 5. If your application involves mostly reads, and very few writes, RAID 5 will perform very well because it has the ability to read in parallel across all the disks in the volume. However, if your application is very write intensive, or even worse, if your application does read-modify-writes, RAID 5 is a very bad choice because the parity has to be calculated or re-calculated for every write and you take a big CPU hit.
My favorite type of RAID for any generic situation where I don't know too much about what the activity will be like is RAID 0+1. The cost can be prohibitive for smaller projects, but you get all the performance benefits of striping, plus the redundancy of mirrors. Just keep in mind that the more you know about the application that is primarily running on the box, the easier it is to make an intelligent choice about what type of RAID to use.
"When the president does it, that means it's not illegal." - Richard M. Nixon
Anecdotal, meaningless statistics.
I don't understand the complaints against software RAID.
Now, perhaps with RAID5, but with RAID 0 or RAID 1, it's not as if there's a whole lot of work for the CPU to do to imlement these schemes.
Ages ago, on a I/O bound Data General Aviion, we took the main database disks, striped them with their software based system utilities (much like IBMs and others).
We instantly, measureably, and Seat Of The Pants got a 50% increase in performance for this application.
If your application is I/O bound and you have "spare cycles" in the CPU, then spending some of those extra CPU cycles to gain I/O performance is worth every command line switch necessary to set it up.
E-mail the HOWTO writer, or locate a Linux Wiki and document those errors as being unmatched DMA settings or potential hardware failure. And leave a spam-proofed email address.
It was an blatant tech support request.
You got the answer you were fishing for without buying the book. The top post should be modded -5 Lazy-SOB
at O'Reilly, mdadm
and, I'd recommend Enterprise Volume Management System rather than LVM ( Logical Volume Manager ), simply because LVM's seems to be being dropped as
redundant ( ironic, that : ) as EVMS gets more effective, and I don't want the conversion-work from LVM to EVMS, if I can just do EVMS right now, see
Messages to/for me ( in me journal )
For IDE hardware RAID accept nothing less than the incredible 3ware (http://www.3ware.com) Escalade series of RAID cards.
These things are AWESOME!
The 7500-12 (parallel version) is relatively cheap since they came out with the 8500 (SATA version) series.
Very good cards indeed.
Plug the 64 bit controller into the 32 bit slot and let the PCI bus be your bottlneck. See their features under minimum system requirements, which specifiy 32 bit or 64 bit. Also, motherboard compatibility, which lists many chipsets without 64 bit pci.
The reason we went with 3ware controllers last time was that we were maxing out the pci bus. Moving to a 64 bit card solved that problem. It's too bad 3ware didn't opt for 66 MHz PCI instead of the wider bus. I wonder how much this has cost them?
but the controller's CPU doesn't need to be that fast, most of the logic is in ASICs anyway. the key advantage to having a controller is that it handles all the drive processing and this reduces the amount of work your main CPU has to do. remember: accessing the drive is not all your machine is doing. also most high-end controllers have large memory caches that reduce the load on your system bus, and battery backup that is essential for data integrity during power-loss. for example, in a mirrored RAID situation a software implementation will have to do 2 DMAs per write, one to each drive. with a hardware controller you only need one DMA to the card, the card handles writing to the individual drives, and will often reorganize the order of the writes from its cache.
Both systems have their pros and cons, here are some points to consider (HWR=HardWareRaid, SWR=SoftWareRAID):
- HWR with cheap controllers also stress the CPU as only parts of the RAID-Code is executed on the card.
- In HWR, you can only RAID whole disks, not partitions.
- HWR controllers need drivers - for some there are no Linux drivers, some are "alpha", some are not included with your favorite distribution etc.
- Booting with SWR can be quite tricky
- The Firmware of HWR controllers can be buggy - getting a fix is probably not that easy as fixing a bug in Linux SWR.
- What happens, if your HWR-Controller fails and you cannot get a replacement? How do you get your data back? This is no problem with SWR.
- Hotplugging is probably better supported with HWR solutions.
- HWR is not necessarily easier to setup. Managing my Mylex DAC960 was a lot harder than setting up Linux SWR.
I would not say that HWR is the only way to go in production systems. It depends somehow on the application. I think, SWR can be more secure in some way. Probably the performance will not be that good as a $1000.- HWR controller, but maybe it's "enough" performance. Why spend $1000 if you just don't need to?
What about a Linux Firewall? RAID performance is no real issue here - but security for the logfiles is.
What I would really like to see is how Linux SWR performs to various HWR solutions. There are some tests on HWR controllers on Tom's Hardware page, but it seems there are no thorough tests on Linux SWR.
/dev/md2:
Timing buffer-cache reads: 128 MB in 0.91 seconds =140.35 MB/sec
Timing buffered disk reads: 64 MB in 2.19 seconds = 29.21 MB/sec
That's 0+1 on UW scsi across 4 drives and two channels. I need to get some ata100 or u160..
Heh, I break my 40 hours on the third day of my 7 day work week... it's fun working for a start up, 2 hours drive (round trip) away from where I live.
or put more simply; two IDE drives stripped on the same channel perform no better than two individual IDE drives joined as a single spanned volume.
Regarding trust; why should I trust open source anything? Even though I am a programmer, am I expected to read through every line of code and understand how it works enough so that... um... what? I can look for buffer overflows? So that if the software fails I can patch it myself? No, I think I'll trust the hardware manufacturer with millions in R&D and years of experience specifically aimed at RAID and drives. If my open sores RAID solution fails, will I have to wonder if some 13 year old norwegien kid's mom is going to let him reply to newsgroup messages after being grounded for downloading porn via IRC again?
Sheesh, a simple typo. Maybe if you weren't such a picky bastard you'd have some "class."
If you just wanted to match the benchmark values of SCSI drives using software raid you might have come close - but in a real world application where your CPUs have to do more than just run the software RAID array - you'll find you've hit yourself hard.
I don't spend a fortune on SCSI drives, I feel $250 is not bad to pay for a 15,000 RPM 8 MB cache Cheeta 36 gig drive. $250 for the fastest single drive on the planet? Sounds like a bargin to me. Now, let me put two of those drives on a $200 RAID card from Adaptec -- lets run that against your ATA100 7200 RPM 2 mb cache IDEs running on a serial interface. OUCH! "Sucks"
more importantly than that, they can write to 4 drives simultanously, which is a big perf win for RAID10.
The read speed on a (non-degraded) RAID5 should be identical to the read speed on a RAID0. It's the writes where RAID5 punishes you.
yep, 1 operation can be 'get a contiguous chunk of a meg'. now, how does that affect the CPU load instead of RAM 'load'?
I've just been through setting up a raid system. I set up a file server that automatically backs up data every week that the users on the network put on it via samba. Since I only want to show up at the place every 6 month or so to check on the server it needs to be bullet proof to the max and still cheap, because they don't have much money as social workers.
:-(, since doku is the last thing those guys seem to think about.
I purchased a used p2 system with a stable mb and two ibm scsi drives on an adaptec controller. I installed Debian GNU/Linux stable and upgraded to the latest stable. Then I put up a softraid and opted for xfs in case of a power failure. I decided against an ups, because I hooked the machine up to the local power network, which is very stable, since the server lives in Berlin/Germany, and I wanted to save the cost.
Then I moved the root filesystem over to the raid device. Up until now everything was documented very good, except for the fact, that I heard that reiserfs doesn't work with softraid and I didn't find that info on the net anymore. I would have taken reiserfs instead if I would have had a reliable source, such as the book, telling me that that is OK.
The only thing I had problems with was how to make the system boot off the raid device. Here the howtos and man pages had contradicting stands on how to do this.
I read this Slashdot article with some regret, because I thought it could have saved me a lot of trouble. But the only section that gave me trouble also seems to confuse the auther of the book. Now that is no help at all. So this book is a waste of time if You know how to use google, which I had to learn painfully fast getting into Debian
But since Debian is still by far the best system out there overall I have no choice. If You start to rely on seemingly simple things such as a reliable update of Your system with very low hassle then You are hooked.
Anyway, I would also like to mention that the Multi Disk HOWTO (homepage) is relevant, includes layout examples and also a trouble shooting guide. A fault tree would of course be nice.
The HOWTO also mentions that there are actually 2 different RAID systems available, do make sure you get the right one and the corresponding tools. Additionally it refers to a number of hardware RAID HOWTOs, of which there are many.
And please, please send feedback. That HOWTO author actively asks for inputs, so why don't you?
Speak for yourself. I'm saying that the CPU utilization is so low that it never impacted my gaming or anything else. The chips are hardware disk controllers. The only thing that is software controlled is the fact that the host CPU tells it to write to seperate channels.
If I was running a P200, then yeah. I could see some sense in your argument. But modern day 1GHz+ CPUs don't even dent under the minimal load on the CPU, when processing instructions for the ATA RAID controllers. It's no worse than say- software controlled DirectSound mixing, or Winmodems.
Hmm I believe that Windows disk mirroring (RAID 1) is actually OK. Despite its dependancy on Dynamic Disks (bleh!) it works transperantly, and imposes little overhead on systems of current spec. If a disk fails, just pull it out and reboot. There is downtime, but it IS software.
"The Green Beret symbolizes all that America stands for" Like power over morality, disgard of basic human rights, blinding following orders of piles of shit pretending to be human beings, and generally using the U.S. Constitution as toilet paper?
Tell her to "Cancel my subscription to the resurrection. Send my credentials to the House of Detention. I have some friends inside".
ALL HAIL KALIMA!!!!
I have started using the Promise SX and RX 8000 external RAID arrays and have nothing but the highest praise for them. For those who aren't familiar with them, they are self contained ATA RAID chassies with 8 hot-swap trays. Each drive is on its own ATA-133 controller and the RAID (0, 1, 3, 5, 10, 30, 50) is handled by an on-board RAID controller with expandable cache, etc (no software RAID). Hot-swap, hot-rebuild, hot-spare, hot-expand, even on the fly RAID level conversion. Connects to my servers via a U160 LVD cable and is treated as a really really big SCSI hard drive...no drivers required. The array is controlled in one of three ways: 1.) Onboard LCD display with soft-buttons, 2.) Serial console, or 3.) Some Windows utility (haven't used it). For exactly $4,025.xx I put together an SX-8000 with 8 Maxtor 200GB 7200RPM drives. Even comes with an LVD cable and a serial cable (for console work). Simply awesome and great bang for the buck. I haven't used the rack-mount version (RX8000) yet, but one is on the way. If you're in need of such RAID, I would highly recommend it. They also make a 4 drive version (RX/SX 4000) and I am told an RX/SX15000 is on the way.
When you mentioned 4x60GB RAID-1, I think you mean RAID-10. RAID-1 is mirroring between two drives. RAID-0 is striping, that is, the data is spread across two drives. RAID-1 with four drives isn't possible, but with RAID-10 (two pairs of mirrors combined), it is.
Pete