• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

RAID6 SSD vs HDD performance

Cerulean

[H]F Junkie
2FA
Joined
Jul 27, 2006
Messages
9,484
Greetings,

I know that for RAID6 the approximate read is supposed to be 3x greater and the write is just 1x (same speed as that of a single drive). If using SSDs in a RAID6 as opposed to HDDs, does this rule still apply, or is performance greater for each SSD you add to a RAID6? :?
 
and the write is just 1x (same speed as that of a single drive).

Being that I have software raid6 arrays (using hard drives) that I can write large sequential files at 700 MB/s I would say this is absolutely wrong.

As for a SSD doing raid6 I suspect the latency will take away partially the biggest benefit of using a SSD.
 
The latency only hurts a bit, but is vastly outshined by the sheer number of IOPs most SSDs can process when compared to mechanical drives. This is why even SSDs with slow transfer rates can sometimes provide a very notable performance boost over mechanical drives.

In actual usage you will gain the biggest performance increases when doing writes involving lots and lots of small writes. Mechanical drives would quickly fill up their command queue with commands to perform these small writes, while an SSD can do the IOPs needed several orders of magnitude faster. So yes you will incur a small latency hit from the raiding of the drives, but I doubt you will even notice any negative effects from it in real usage.
 
Being that I have software raid6 arrays (using hard drives) that I can write large sequential files at 700 MB/s I would say this is absolutely wrong.
Agreed on this point. The first time last time I put together a RAID-Z array I did a benchmark of an individual drive and the finished array for writing a large file. The array did outperform an individual drive by quite the margin. (hammered the CPU to hell and back but it was a rather low end cpu at the time)
 
It depends on how large the writes are. If you're writing more than (stripe size) * (# disks) then parity can be calculated from new data alone and write speed to the array will be (# disks - 2) * (individual disk write speed), however if you're updating a small amount of data it has to first read the existing data you're about to write and also the parity data from both drives storing that particular parity, then recalculate the parity based on the old and new data, then write the new data back to the drive. This is the "write penalty" because before it can write one piece of data it has to read 3 from 3 different drives, then write all 3 back. 6 physical IO for 1 IO to the array.

HDD or SSD doesn't change any of this.
 
Implementation will be key here, between a good and a bad RAID card/software RAID, performance will be night and day. I would question the idea of using RAID6 on SSDs, though, over RAID5/hotspare.
 
Implementation will be key here, between a good and a bad RAID card/software RAID, performance will be night and day. I would question the idea of using RAID6 on SSDs, though, over RAID5/hotspare.

Good point. Rebuild time should be really short and it avoids a lot of writes to the spare. Also SSDs tend to fail mostly due to writes, decreasing the probability of a second failure during rebuild.
 
Also SSDs tend to fail mostly due to writes

I thought it was more of random controller failure. Although I suspect only the manufacturers really know.
 
Back
Top