On 04/20/2012 11:58 AM, David Brown wrote:
> Hi,
>
> Yes, being a generator for GF(2^8) is a requirement for a parity
> generator (sorry for the confusing terminology here - if anyone has a
> better suggestion, please say) to be part of a 255 data disk system.
> However, being a GF generator is necessary but not sufficient - using
> parity generators (1, 2, 4, 16) will /not/ give quad parity for 255 data
> disks, even though individually each of 1, 2, 4 and 16 are generators
> for GF.
>
> 255 data disks is the theoretical limit for GF(2⁸). But it is a
> theoretical limit of the algorithms - I don't know whether Linux md raid
> actually supports that many disks. I certainly doubt if it is useful.
>
> It might well be that a 21 data disk limit quad parity is useful - or at
> least, as useful as quad parity ever would be. It would fit well within
> a typical large chassis with 24 disk slots. And then it doesn't matter
> that 8 is not a generator for GF(2⁸) - it becomes the best choice
> because of the easiest implementation.
>
It is also worth noting that there is nothing magical about GF(2^8). It
is just a reasonable tradeoff when tables are needed.
There are hardware tricks one can play to do efficient operation of
wider fields, too.
But It sounds like {04} or {8e} are particular interesting generators of
the existing GF(2^8) field for an efficient second field, giving
triple-parity RAID again at a reasonable cost.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
