I've been reading: http://community.netapp.com/t5/Tech-OnTap-Articles/Back-to-Basics-RAID-DP/ta-p/86123
That basically describes RAID-DP as diagonal parity raid. But there's one thing that's bothering me a bit - this example must be simplified, because it describes taking a sum. That's fair enough - for 'normal' parity in RAID4 and RAID5 - you do XORs rather than straight additive sums and this works because XORs are quite efficient and you can reconstruct.
If your parity is:
A xor B xor C = P
Then
P xor B xor C = A
There's just one thing that's nagging at me a bit though - The DP sum can't work that way, because if you do an 'XOR style' dual parity... you end up with an ambiguous result. You create a bunch of simultaneous equations, that allow you to figure out the relationships between bits - e.g. you know which bits are equal and not equal to each other. However, you end up with two valid solutions - one the 'inverse' of the other.
I assume that's why the worked example uses additive sums... but the thing that bothers me about that is: Your additive sum will often be a bigger number of bytes than the source. If you 'sum' 10 values a byte long, and your sum might be bigger than a byte. You could 'wrap' your sum I guess, but you still risk getting an ambiguous result.
What your parity effectively tells you is which bits are equal to each other and which aren't. But the net result is ambiguous - you can either have the 'right' answer, or an inversion of the 'right' answer.
What am I missing?
(I suspect the answer might be similar to how RAID-6 does it).
Maybe http://www.netapp.com/us/media/tr-3298.pdf which has more details and references can help you understand the design?
Don't worry about the result not fitting for addition. Just ignore the overflow. There is no ambiguity. For example, let's imagine buckets that hold a single decimal digit.
5 + 4 + 8 + 3 + 6 => 26.
Since it only holds one digit, we'll just write "6" for parity. Now we need to reconstruct the fourth data digit. The inverse for addition is subtraction:
6 - (5 + 4 + 8 + 6) => -17 Just add "10"s to it until you get a positive number, and 3 is the missing value.
You're right that for dual disk, you can't work on a single row and recover the information. You must be able to read multiple rows. Here is a USENIX paper that covers an algorithm for row diagonal parity.