On Sat, Oct 27, 2012 at 12:35 PM, Jim Klimov <jimkli...@cos.ru> wrote:

## Advertising

> 2012-10-27 20:54, Toby Thain wrote:
>
>> Parity is very simple to calculate and doesn't use a lot of CPU - just
>>> slightly more work than reading all the blocks: read all the stripe
>>> blocks on all the drives involved in a stripe, then do a simple XOR
>>> operation across all the data. The actual checksums are more expensive
>>> as they're MD5 - much nicer when these can be hardware accelerated.
>>>
>>
>> Checksums are MD5??
>>
>
> No, they are fletcher variants or sha256, with more probably coming
> up soon, and some of these might also be boosted by certain hardware
> capabilities, but I tend to agree that parity calculations likely
> are faster (even if not all parities are simple XORs - that would
> be silly for double- or triple-parity sets which may use different
> algos just to be sure).
>
I would expect raidz2 and 3 to use the same math as traditional raid6 for
parity: https://en.wikipedia.org/wiki/Raid6#RAID_6 . In particular, the
sentence "For a computer scientist, a good way to think about this is that
<operator> is a bitwise XOR operator and <g superscript i> is the action of
a linear feedback shift register on a chunk of data." If I understood it
correctly, it does a different number of iterations of the LFSR on each
sector, depending on which sector among the data sectors it is, and that
the LFSR is applied independently to small groups of bytes in each sector,
and then does the XOR to get the second parity sector (and for third
parity, I believe it needs to use a different generator polynomial for the
LFSR). For small numbers of iterations, multiple iterations of the LSFR
can be optimized to a single shift and an XOR with a lookup value on the
lowest bits. For larger numbers of iterations (if you have, say, 28 disks
in a raidz3), it could construct the 25th iteration by doing 10, 10, 5, but
I have no idea how ZFS actually implements it.
As I understand it, fletcher checksums are extremely simple and are
basically 2 additions and 2 modulus per however many bytes at a time it
processes, so I wouldn't be surprised if fletcher was about the same speed
as computing second/third parity. SHA256 I don't know, I would expect it
to be more expensive, simply because it is a cryptographic hash.
Tim

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss