RAID 6 is a newer member of the RAID family. It was added several years after the other levels had become standardized. RAID 6 is special in that it allows for the failure of any two drives within an array without suffering data loss. But to accommodate the additional level of redundancy a RAID 6 array loses the storage capacity of the equivalent to two drives in the array and requires a minimum of four drives. We can calculate the capacity of a RAID 6 array with ((n-2)*s).
Many vendors use the term RAID 10 (or RAID 1+0) when speaking of only two drives in an array but technically that is RAID 1, as striping cannot occur until there are a minimum of four drives in the array. With RAID 10, drives must be added in pairs so only an even number of drives can exist in an array.
RAID 10 can survive the loss of up to half of the total set of drives but a maximum loss of one from each pair. RAID 10 does not involve a parity calculation, giving it a performance advantage over RAID 5 or RAID 6 and requiring less computational power to drive the array. RAID 10 delivers the greatest read performance of any common RAID type as all drives in the array can be used simultaneously in read operations. But its write performance is much lower. RAID 10's capacity calculation is identical to that of RAID 1, (n*s/2).
In today's enterprise it is rare for an IT department to have a serious need to consider any drive configuration outside of the four mentioned here, regardless of whether software or hardware RAID is being implemented. Traditionally the largest concern in a RAID array decision was based around usable capacity. This was because drives were expensive and small.
Today drives are so large that storage capacity is rarely an issue, at least not like it was just a few years ago, and the costs have fallen such that purchasing additional drives necessary for better drive redundancy is generally of minor concern. When capacity is at a premium RAID 5 is a popular choice because it loses the least storage capacity compared to other array types. And in large arrays the storage loss is nominal.
Today we generally have other concerns, primarily data safety and performance. Spending a little extra to ensure data protection should be an obvious choice. RAID 5 suffers from being able to lose only a single drive. In an array of just three members this is only slightly more dangerous than the protection offered by RAID 1.
We could survive the loss of any one out of three drives. Not too scary compared to losing either of two drives. But what about a large array, say, sixteen drives? Being able to safely lose only one of sixteen drives should make us question our reliability a little more thoroughly.
This is where RAID 6 stepped in to fill the gap. RAID 6, when used in a large array, introduces a very small loss of storage capacity and performance while providing the assurance of being able to lose any two drives. Proponents of the striping with parity camp will often quote these numbers to assuage management that RAID 5/6 can provide adequate "bang for the buck" in storage subsystems. But there are other factors at play.
Almost entirely overlooked in discussions of RAID reliability an all too seldom discussed topic as it is is the question of parity computation reliability.
With RAID 1 or RAID 10 there is no "calculation" done to create a stripe with parity. Data is simply written in a stable manner. When a drive fails its partner picks up the load and drive performance is slightly degraded until the partner is replaced. There is no rebuilding process that impacts existing drive members. Not so with parity stripes.
RAID arrays with parity have operations that involve calculating what is and what should be on the drives. While this calculation is very simple it provides an opportunity for things to go wrong.
An array control that fails with RAID 1 or RAID 10 could, in theory, write bad data over the contents of the drives but there is no process by which the controller makes drive changes on its own. So this is extremely unlikely to ever occur, as there is never a "rebuild" process except in creating a mirror.