Slashdot Mirror
RAID Controller Shoot-Out
mikemuch writes "ExtremeTech has a comparison with benchmarks of three RAID controllers from Adaptec, LSI Logic, and Promise, and along the way gives you a little refresher course on RAID in general and why you want to use it: faster throughput, longer uptime, and improved data security. Motherboard RAID controllers do well when there's 'very little or no load on the CPU, I/O bus, and memory bandwidth. But with heavy traffic and processor loads, the limitations of the shared bus and the benefits of intelligent RAID's integrated IOP and memory cache have a more significant impact.'"
The vast majority of onboard RAID "controllers" I've encountered so far have been little more than a software driver. And a Windows-only one at that.
Actually, if you get two reliable drives (vs. cheap pieces of crap) RAID0 is awesome. Especially if you get high rpm (10,000 or 15,000) drives. While there is no redundancy in RAID0, it greatly increases any loading from hard drives -- this doesn't matter to the average user, but to someone who's loading large files all the time (CAD work, gaming, etc.) it makes the world of difference.
A computer once beat me at chess, but it was no match for me at kick boxing.
Sometimes all you care about is the maximum performance you can get out of a disk subsystem. You might not care about data loss because you've some other means of taking care of it (backups, replication, network raid etc.), or the data is dispensable. An example is a cluster of high performance database servers, with replication taking care of the data redundancy and a raid 0 disk subsystems because thats the best raw performance you can get.
I've used some RAID controllers myself, and I have friends with a lot of experience with them. A key factor in what makes a good RAID controller is not throughput. It's long-term reliability. How long can you hammer your RAID array before you get unrecoverable corruption? A RAID array is supposed to prevent that, but if you have some weird bug in your RAID controller, or it's susceptible to EM interference from surrounding components, you will get data corruption. And I don't mean for reads; I mean that the data gets corrupted on the way from memory to the disk (at least that's our theory), where no RAID controller can protect you.
Of ATA controllers, our experience shows that 3ware controllers are the least unreliable. That is, they generally suck, because they have demonstrated performance problems and other weird failures that 3ware couldn't help us resolve, but they suffer from the least data corruption.
For whatever reason, the on-board controllers are the worst. They seem nice and perform well enough, but they have the highest rate of data corruption.
It may or may not surprise you that software RAID is relatively reliable. With a RAID1, you'd think you're twice as likely to corrupt data on writes, because you have to send the same data twice to two different drives. Sure, having them both bad is unlikely, but at a later time, how do you know which copy of a given sector is correct? But we think that removing an unreliable hardware RAID controller from the data path and just having the relatively simple ATA controller in the way reduces chances of a problem. Just a guess.
If you want truly reliable hardware RAID, you need to spend your life savings on an industrial-strength SCSI RAID controller.
The moral of the story is that there's really no such thing as 100% reliable data storage. If you want speed and don't care about reliability, RAID0 is for you. Other RAID levels add redundancy, which is nice in theory, but add hardware complexity that offsets some of the advantage. For my critical data, I store to CD and DVD ROM. And I make multiple copies of those, because those aren't all that reliable either.
I second the Areca recommendation. Their cards are very capable of detecting a failed disk, taking it offline, mailing the operator, and sounding the buzzer, all without skipping a beat as far as the host operating system can tell. And their RAID engine is bleeding fast, too. I just wish the kernel folks would try harder to get their driver into the mainline. Areca is the rare example of a manufacturer who undertook the cost to write their own Linux driver and release it under the GPL, and the kernel maintainers have spent more than a year whining and bitching about how the code doesn't fit in their 80-column terminals.