Triple-Parity RAID and Beyond - ACM Queue

Triple-Parity RAID and Beyond - ACM Queue: "A Classification
for Triple-parity RAID

None of the existing RAID classifications apply for triple-parity RAID.  ... The next obvious choice is RAID-7, but rather than applying the designation merely to RAID with triple-parity protection, RAID-7 should be a catch-all for any RAID technique that can be extended to an arbitrary number of parity disks. Specific techniques or deployments that fix the number of parity disks at N should use the RAID-7.N nomenclature with RAID-7.3 referring to triple-parity RAID, and RAID-5 and RAID-6 effectively as the degenerate forms RAID-7.1 and RAID-7.2, respectively."
'via Blog this'

I reject this RAID-7 terminology.  Or, rather, I find this terminology not useful - not useful for thinking about, explaining, extrapolating.  If Marketing needs to use RAID-7, fine, let them - I will translate to what



The original RAID terminology was never coherent, arbitrary numbers, mixing considerations like bit, byte, and block level, dedicated parity disk versus rotating the parity, etc.



More and more, I am starting to use meaningful notations like

• Rd+p = redundancy, with d data disks and p parity (or other) disks.
• e.g. assuming striping at fixed size block level, and that all rotate parity 
• Rd+1 = classic RAID-4, with d data disks and 1 parity disk, 
• R4+1 = 4 data disks + 1 parity disk
• R2+1 = 2 data disks + 1 parity disk
• R3+1 = three data disks + 1 parity disk
• R1+1  = ??  arguably, a mirror, see below
• Rd+2 = d data disks + 2 parity = classic RAID-6
• Rd+3 = RAID-7 as proposed above, with triple parity

By default we may assume that there are stripes that contain all of the data disks and parity disks.

However, there is value in thinking about different nesting or grouping for higher levels of parity or reconstruction codes.  e.g. L1-parity may be within a stripe, L2-parity may be across a stripe of stripes, i.e. recursively nested, or across a different stripe that intersects the current stripe in only one disk. The write overhead grows in either case, especially for partial stripe writes, but less with intersection than inclusion.

I.e. you may have Rd+p, but you may have D > d+p disks.  No, I don't have a good notation.

An extension to the notation describes not the amount of redundancy, but also how many disks can be lost.

E.g. Rd-f, with d data disks, able to tolerate the failure of f disks.

Typically   Rd-f => Rd+f,  but not necessarily logical/physical  storage proportional to d/(d+f).  As mentioned above, the reconstruction codes may be calculated on nested or intersecting groups, e.g. R4+1 groups nested in an R12+1 group 4/5*12/13 = 48/65.  (Assuming that this is truly R*-2.)  (I am not advocating this, or even asserting that this is possible -m I just want a notation that can describe it.)