WD Caviar Black 640 x2 raid 0

karan_kewlz

Distinguished
Apr 30, 2010
80
0
18,630
I am planning on buying two WD caviar black 640 GB drives and put them in raid 0. My questions are :

1. Should i keep the block size 32kb or 64kb

2. is x2 caviar black 500 GB in raid 0 better than the above config

3. have the single platter versions of 500 GB caviar black arrived (if so, what's their model no. and in this scenario will the x2 caviar black 640 GB in raid 0 be better ?)

4. I have 1 tb seagate HDD which is almost full, is it possible without (taking backup) to keep this drive out of raid array and use it as a simple logical drive.

one more question, I am using 790i ultra sli board, does this have a hardware RAID controller or a firmware based (that will transfer load to my CPU)

(I'm using windows 7 x64, 6 GB ddr3 1333 mhz, q9550 and use it 90% for hardcore gaming)

thanks in advance
 
Solution
WD Blacks do not have TLER so any bad sectors arising from BER (Bit Error Rate) would cause that disk to be disconnected/dropped from the array. This problem is very widespread and basically happens with all hardware and windows software RAIDs.

As i understand, the basic root of the problem is RAID engines not being able to distinguish a failed disk from a disk that is performing error recovery and thus times out its read request. The RAID engine would assume the disk is failed and drops the disk from the RAID. As long as you don't encounter bad sectors (Current Pending Sector (C5) in SMART output) you shouldn't have this problem. non-Windows software RAID is not affected by this problem; and thus can use 'cheap' disks in RAID without...
Strange that the WD blacks do not work in Raid0 as I've beeing using them since I put my E6400 together (about 2 years).

On strip size vs cluster size, There were several discussions on on that topic (Google strip size for Raid0). For boot drive + programs I think the general trend was toward the smaller size (Over half of files are under 16K). If looking at performance, google "Short Stroke" - you gain performance, but lose space.
 

sub mesa

Distinguished
WD Blacks do not have TLER so any bad sectors arising from BER (Bit Error Rate) would cause that disk to be disconnected/dropped from the array. This problem is very widespread and basically happens with all hardware and windows software RAIDs.

As i understand, the basic root of the problem is RAID engines not being able to distinguish a failed disk from a disk that is performing error recovery and thus times out its read request. The RAID engine would assume the disk is failed and drops the disk from the RAID. As long as you don't encounter bad sectors (Current Pending Sector (C5) in SMART output) you shouldn't have this problem. non-Windows software RAID is not affected by this problem; and thus can use 'cheap' disks in RAID without cause for alarm. It is hardware RAID and onboard Windows RAID which would need TLER to prevent array splits.

Also WD Black's would develop bad sectors due to BER 10 times more often than the 5400rpm versions, if you believe the specs. Strangely, the firmware-enhanced RAID editions get the same spec as 5400rpm disks; which i seriously question as the disks are not physically different and only differ in programmed firmware; to earn some extra money from customers paying for the TLER feature and longer warranty period.

And perhaps another misconception: many people seem to believe smaller stripesizes are good for small files, and large stripes are good for large files. My tests indicate the exact opposite. And it makes sense: better for both disks to handle a completely different file than for each disk to transfer a chunk of the same file, but requiring both to seek to the same file.

As such, stripesizes of 4 megabytes proved very good for random I/O, but were too high for sequential I/O to saturate all the disks. Thus here a large stripesize was excellent for random I/O but poor for sequential I/O.

I do have to to add these tests are on FreeBSD. Windows onboard drivers are less sophisticated. Some even transfer the whole stripesize even if a fraction was requested; a low-level tweak or optimization used for enhance HDtune benchmarks but having bad real-world performance effects.

If you want to review the benchmark results, they are on my site (geom_stripe benchmarks).
 
Solution