SATA PT2

[Monty J. Harder]

On 6/6/07, Phil Thayer <phil.thayer at vitalsite.com> wrote:
>
>  This is an interesting idea.  You would still have the vulnerability of a
> stripeset with "A" and "B" where a failure of a single disk would cause the
> loss of data from two  stripesets.  Not sure I would want that.  If your
> concerned about utilizing all the drive space on disk drives with different
> sizes you may be SOL on that unless you use a SAN disk virtualization
> methodology.
>

I guess I didn't explain that well:

D1 AAAAAAA
D2 AAAAAAABB
D3 AAAAAAABB
...
DN AAAAAAABBZZZZZ

The As represent data that is MIRRORED across all N drives, not STRIPED,
while the Bs are only MIRRORED across drives 2-N, because D1 isn't big
enough to cover that area.  We start with mirroring and use it until the
space is used that way, at which point we start converting to RAID-5
striping.

If the same XOR is on two disks, it does NOT provide the same functionality.

Let's say we have 6 drives, and we use 4 data blocks and two parity blocks:

 D1 D2 D3 D4 P1 P2
If I lose any ONE of the data blocks, I can recover it by XORing the
remaining 3 data blocks with a parity block.  But if  I lose two data
blocks, I'm screwed.  I can tell what the XOR of corresponding bits in those
two blocks are, but there's no way to know if a 0 was 0^0 or 1^1, or a 1 was
1^0 or 0^1.

Now, if P1 were the XOR of all four, and P2 were only D1^D2, the two of them
together could generate D3^D4 that would help if one lost drive were D1 or
D2 and the other were D3 or D4, but not if D1 and D2, or D3 and D4, or P1
and either D3 or D4 were the two lost.

And the case of P1=D1^D2 and P2=D3^D4 is simply two RAID 5's striped
together (as 'RAID 50'?).

As for figuring out the second parity calculation on RAID 6, what the
> manufacturers are realizing is that they don't necessarily have to have a
> different parity algorithm to calculate the second parity.  Simply putting
> the same XOR parity data on two separate disks will provide the same RAID 6
> functionality as having a second parity calculation with lower overhead on
> controllers.  The old KISS methodology is coming back into play.  I think
> you will see more and more of the manufacturers going this route.
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kclug.org/pipermail/kclug/attachments/20070606/9aca9752/attachment-0001.htm