Old thread, but I decided to come back to it...

Another thing I might have liked to see in this review was for other on-mainboard SATA RAID controllers to be included. And example would be my MSI K8N Neo 4 Platinum mainboard, which has a Silicon Image 4-port SATA RAID controller in addition to the standard nVidia nForce 4 Ultra SATA (I haven't been able to find out if the nForce controller has been updated in BIOS to support RAID-5, so at this point I doubt it). There are a number of boards still using additional onboard SATA RAID controllers, and to know their performance would certainly be useful to others.

I appreciate the review, though. This is exactly the sort of information we need. I'd like to have a RAID-5 setup in my machine at some point. It's difficult to back up nearly half a terabyte of data, so having some redundancy without sacrificing too much performance would be a real plus.

A friend of mine pointed me to this review -- and I'm sadly disappointed with it.

Your comparison of all the RAID types is "wonderful" for anyone who has absolutely no clue about drive cache size, stripe width, and filesystem block size. No where did you mention what stripe width you picked, nor did you mention anywhere what block size you chose when formatting the filesystem (which I assume is NTFS). What you picked for a stripe width also matters depending upon the # of drives you have in the array.

Also, I'm completely and utterly baffled by why you bothered comparing different media types in your "File Copy" section. In fact, I'm even more boggled by the fact that an ISO file vs. an MP3 file makes a difference. IT DOESN'T (assuming the files are the same size). Comparing that to, say, copying a Windows CD (or WHATEVER you're copying; you labelled it "Windows") -- which is going to be very different, since there's a ton of small files (vs. one large file). Something is obviously wrong with your setup, or you forgot to power-cycle your machines before doing each copy. There is definitely some sort-of behind-the-scenes caching going on, because all of those should copy *at the exact same speed*. Either that or your "File Copy" application being used to perform benchmarks is horribly HORRIBLY broken.

I recommend you follow up to this article in the near future with a "Phase 2" revision, going over more details and actually providing graphs + performance comparisons between different stripe widths and block sizes. Do *NOT* change drives (or drive PCBs) during this, either; for example, some drives perform better with smaller stripe widths (believe it or not!), while other drives/models perform better with larger. On-drive-PCB cache plays a role here, but so does drive firmware and other factors.

Sorry if I come off as crass or very judgemental, but I'm a UNIX administrator who's worked with not only pure hardware RAID (3ware, EMC heads, Sun T3 heads, Netapp Filers, etc.), but software RAID (vinum, gvinum, ccd, Linux md, etc.) as well.

Also, for what it's worth: ICH7 and NF4 are both considered software RAID in the UNIX world. They do very _VERY_ little hardware offloading (the majority of time is spent in the Windows driver), and obviously have no dedicated I/O cache (compare this to hardware RAID solutions where you're sporting 1GB of battery-backed cache :) ).

Hope this helps. Good luck in the future.

#66
in a 0+1 situation, you're mirroring a stripe. if one one of the stripes go down, that entire section of the array is offline; i.e. non of the hard drives making up that block is ever accessed, so the chances of any of them every failing is very low. in a 10 situation, you're striping a mirror, so you can lose a drive, and then lose another drive drive that's not the mirror of any previously lost drive.
Further, once you go about reinitializing the array after a drive loss, in a 0+1 siutation you need to mirror an entire set. In a 10 situation you mirror the lost drive(s).
e.g. if ABCDEF are data blocks, in 0+1 they'd be arranged as
A-B A-B
C-D C-D
E-F E-F

but in 10 they'd be
A-A B-B
C-C D-D
E-E F-F

it's very simplified but it's easy to see why 10 would be more fault tolerant.

Hate to be critical considering how much work must've gone into this review but I think you should've included the results of tests with a real hardware RAID card in this review, like the Areca 1210 PCIe x8. Would've been a great way for people to compare a software RAID to a hardware RAID array performance wise.

Can i ask? How do i create a Raid 0 that have 3 disk's?
I have been runing Raid 0 on 2 disk's for the last cupel of years.

Thank you for a great aticel on Raid's =)

Best R. Thomas Persson
IT Doktor Stockholm Sweden
www.cas2.com

Despite the need to calculate parity, the CPU utilization of our RAID 5 arrays is quite reasonable.

Why do people keep claiming this? I have never seen anyone show that software RAID incurs significant CPU overhead. Is there any need to offload XORs to a dedicated card when the CPU can XOR at GB/s rates?

No matter how we see it, RAID isn't worth the effort for desktop users.

The best thing I can do for myself is to have all the work files and the Outlook ones on an external disk, with an automatic backup twice a day.

If my system fails, I connect the disk to my laptop and that's it (I can't be offline during the day, even if the sun turns off).

RAID is good for servers but, from my point of view, the chance the primary disk fails is the same than either the video card, the power supply, the motherboard, the processor or the memory fails. So, a RAID system is only marginally safer than a normal one... And I still safer with an external disk and a laptop...

The limited write performance of raid5 isn't (only) because of needing cpu to calculate xor.

In a 4 drive raid5 array, you could have the blocks data1, data2, data3 and parity(1,2,3) on each drive.

If you need to write just data2, you can't just calculate the parity and write data2 and parity(1,2,3), you need to read first. You could read data1 and data3, combine them with the new data2 (in buffer) to calculate parity(1,2,3).

This has a lot of latency compared to raid 0/1/10/0+1, that doesn't need to read first, but can just write the block to the drive(s) (raid0 = 1 drive, raid 1/10/0+1 = 2 drives to keep mirrored).

OK, so I have only had time to skim though, but:
Great review of performance. Pretty exhaustive.

But that's only half the story. What about redudancy? Did you test that at all? Pull the power from a drive mid-write (or mid-read)? Damage a cable?

I've heard some pretty painful stories about people having great difficulty getting some of these entry-level RAID systems going again after a failure.

What a great article. I ran a stripe set and RAID 5 for a while on my gamining rig and noticed no real speed difference. Keep in mind this was on a NF3 + 3Ware 6400 card, so old, but quite usable.

The time and detail is why TR is my homepage. As other things as well.

what i've always wanted to see is the statistical rate of array failure in a mathematical equation for each of the RAID types. more than just "RAID 0 takes 1 drive to fail" - i'd like to know with an assumed drive failure rate of X, what is RAID 0's probability of failure. and the same for RAID 1, RAID 5, etc.

but then, i'm a math junkie. also, i really don't like the arguments of "which RAID is better for redundancy" that always seem to spring up around these kinds of discussions. ;)

well done, gentlemen.... well done!

Another over-the-top, graph-o-rama article. Great job on this one.

You could always add to the review since you still have the drives by picking up hardware based cards, IF you wanted to.

The article is still impressive the way it is.

I kept having this flash thru my mind while reading it though:

The is no StorageReview in Techreport, dag-nabbit!

no surprise on the sorry RAID 5 performance. It would be nice to see a Windows Software RAID in comparison though, since most onboard solutions are host based solutions anyway (aka fakeraid).
Even a cheap XOR raid5 card (~150) will smoke these 4 drive array results by at least 5x.

One thing:
Wouldn't it be more logical to relabel the RAID0 (and RAID10/0+1 by association) picture with A1-A2, B1-B2 etc. ? To point out the splitting of data.
For RAID5 that would make: A1-A2-A3-P(A)

my €0.02 on that :).

That's a lot of graphs :-o

Excellent article, fellas. There's an incredible amount of useful info in here. It's a wonder we haven't been crippled by /. yet.

Only way I can think to improve it woudl have been to knock out a drive or two while the arrays were operating, just to see what would happen.

With respect to the IO bottleneck of 16, have you seen these type of settings and have you ever tested with them?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpqcissm\Parameters\Device]
"NumberOfRequests"=dword:000000FF
"MaximumSGList"=dword:00000081

Excellent review. I've been looking at RAID 10 systems a lot recently and I put one together at work that is SCSI based. It would have been interesting to see how a 3rd party HBA (such as the Promise TX4300 or SX4300) would have compared to these chipset controllers. Great job!

Is it me or does the nf4 single disk rig need 24 seconds, or *50%* longer to boot than the intel?
That spread remains steady through the tests on that graph.

Is the difference all in the raid boot bios or something?

NIce work! It examplifies what I knew all along about RAID. RAID does little for most desktop users. At most it will provide fault tolerance that's about it. RAID really belongs to servers and heavy-duty workstations. A bunch of seperate single HDDs work better for desktop users.

Just a little reminder, if you value your data. BACK IT UP! RAID just saves you from a potential HDD failure, but does nothing against software related data corruption.

If I didn't know better, I'd guess you got paid per graph.

That was insane. Great work.