In today’s episode our hero, always searching for ever higher levels of resiliency, adds a second parity strip, sticks a feather in his cap and calls it RAID6.
RAID5 systems protect user data against a single device failure, but leave data vulnerable to multiple device failures and more significantly read failures from otherwise working drives during a rebuild.
RAID6 technologies were developed to further increase system resilience by adding a second parity block. As a steely-eyed storage guy, I love resilience.
RAID 6 Data Layout, Diagonal Second Parity
Different implementations of double parity RAID have used several different mathematical algorithms to calculate the second parity, or erasure code, block. These algorithms include Reed-Solomon codes and diagonal parity.
For simplicity’s sake well use RAID6 as an inclusive term to include any scheme that stores two rotating strips of ECC along with X strips of unmodified data. We’re also going to follow the common convention of, as with RAID5, calling the first parity strip P and the second strip Q.
Where the general formula for RAID5 is:
X(Total number of drives)=nD+P
X=nD+P+Q or X=nd+2P
Just as with RAID5, the computational overhead of double parity was significant compared to the processors available when it was first proposed. Now, the load on today’s processors is minimal, making any advantage one method has over another in CPU consumption moot.
RAID6’s biggest advantage is that it provides the highest resilience level of any of the common data protection schemes. A RAID6 RAIDset can survive two drive failures and still keep operation– or as John Cameron Swayze used to say “Takes a licking but keeps on ticking”.
While ensuring data integrity isn’t, strictly speaking, a concern of RAID (it was never discussed in the Patterson paper) the second parity drive also provides a source of authority in the event there’s a read error of some sort during the period the RAIDset is in degraded mode.
Like other parity RAID systems, small writes to a RAID6 set create a read-modify-write process that amplifies one I/O request into many. Exactly how many will depend on the encoding method for the second parity strip and other implementation factors.
However, a simple rule of thumb is that a RAID5 set demands roughly four I/Os from its back-end drives for each write I/O requested, while a RAID6 set demands six.
Over the past decade or so, double parity has become the default data protection scheme for many storage systems and users. Modern storage systems work around the small write I/O amplification by aggregating multiple small writes in a memory log, always destaging from the log to the disks in full RAID stripes.
NetApp’s RAID-DP uses a pair of dedicated parity drives as an extension of RAID4. By contrast, most RAID6 implementations use a variation on RAID5’s rotating parity. While this may create a performance problem for small write I/O’s NetApp’s log-based WAFL file system doesn’t perform small I/Os.
That pretty much covers RAID, the common ancestor of all of today’s data protection methods. Please remember that our discussion so far has been pretty theoretical.
A large number of very smart engineers have spent the past 20 years coming up with variations on one or more of the basic RAID levels; as the old song said “Eventuate the positive, eliminate the negative”
The result is that we have products that are much better than what RAID promised in 1987. We’ll talk about caching, compound RAID, and switching the D from Drive to Data to create the distributed chunklet and erasure codes that are de rigueur today in future installments.
One closing thought: Higher RAID numbers are not necessarily better. I’ve lost count of the number of servers I’ve seen that have a three-drive RAID5 set when the boot volume is smaller than a single drive and RAID 1 would have provided a similar level of resilience with just two drives and performed better.