> Don't hear about triple-parity RAID that often: I agree completely. In fact, I have wondered (probably in these forums), why we don't bite the bullet and make a generic raidzN, where N is any number >=0.
In fact, get rid of mirroring, because it clearly is a variant of raidz with two devices. Want three way mirroring? Call that raidz2 with three devices. The truth is that a generic raidzN would roll up everything: striping, mirroring, parity raid, double parity, etc. into a single format with one parameter. If memory serves, the second parity is calculated using Reed-Solomon which implies that any number of parity devices is possible. Let's not stop there, though. Once we have any number of parity devices, why can't I add a parity device to an array? That should be simple enough with a scrub to set the parity. In fact, what is to stop me from removing a parity device? Once again, I think the code would make this rather easy. Once we can add and remove parity devices at will, it might not be a stretch to convert a parity device to data and vice versa. If you have four data drives and two parity drives but need more space, in a pinch just convert one parity drive to data and get more storage. The flip side would work as well. If I have six data drives and a single parity drive but have, over the years, replaced them all with vastly larger drives and have space to burn, I might want to covert a data drive to parity. I may sleep better at night. If we had a generic raidzN, the ability to add/remove parity devices and the ability to convert a data device from/to a parity device, then what happens? Total freedom. Add devices to the array, or take them away. Choose the blend of performance and redundancy that meets YOUR needs, then change it later when the technology and business needs change, all without interruption. Ok, back to the real world. The one downside to triple parity is that I recall the code discovered the corrupt block by excluding it from the stripe, reconstructing the stripe and comparing that with the checksum. In other words, for a given cost of X to compute a stripe and a number P of corrupt blocks, the cost of reading a stripe is approximately X^P. More corrupt blocks would radically slow down the system. With raidz2, the maximum number of corrupt blocks would be two, putting a cap on how costly the read can be. Standard disclaimers apply: I could be wrong, I am often wrong, etc. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
