Re: [PATCH 1/4] md: Factor out RAID6 algorithms into lib/

Gregory Maxwell
2009-07-17T19:12:34Z

On Fri, Jul 17, 2009 at 11:49 AM, H. Peter Anvin<hpa@zytor.com> wrote:
> Ric Wheeler wrote:
>>>
>>> The bottom line is pretty much this: the cost of changing the encod=
ing
>>> would appear to outweigh the benefit. I'm not trying to claim the L=
inux
>>> RAID-6 implementation is optimal, but it is simple and appears to b=
e
>>> fast enough that the math isn't the bottleneck.
>>
>> Cost? Thank about how to get free grad student hours testing out thi=
ngs
>> that you might or might not want to leverage on down the road :-)
>>
>
> Cost, yes, of changing an on-disk format.

In the context of BTRFS the only costs are development of the new
erasure code and integration as well as the possible cost of carrying
around two erasure codes (one for MD backwards compatibility, one for
BTRFS).

The availability of arbitrary M of N erasure codes is more attractive
for BTRFS than MD because of the increased granularity. I.e. with
BRTFS you might want a smaller stripe width because some sub-volume
spans fewer spindles, or increased parity blocks you need increased
redundancy for some small set of files.

On the other hand=E2=80=94 for performance reasons if you want addition=
al
redundancy beyond 'RAID6' you might just be better off writing more
duplicates of the data blocks instead of additional RS syndromes since
while the additional data blocks are not optimal from an error
recovery perspective they will provide a performance gain of being
able to spread reads out across additional disks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html