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


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?

| improve this answer | |
  • I've been following that sort of thing, but it uses addition sums for it's illustration. The problem with that approach is - you cannot add the values of 5 bytes, and have the sum always fit in byte sized parity block. That's why - instead of addition - XORs are used for RAID4 and 5. XOR cannot work for DP though, because you get two equally valid solutions. I'm speculating that the way to handle this is having a known value on e.g. byte zero of the disk. – Sobrique Oct 22 '14 at 13:42
  • 1
    Disks are pre-zeroed. Did you check the theorem for these kinds of details? usenix.org/legacy/publications/library/proceedings/fast04/tech/… – Chris Madden Oct 24 '14 at 9:44

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.