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

[David Woodhouse <dwmw2@infradead.org>]

On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote:
> Ric Wheeler wrote:
> >>
> >> The bottom line is pretty much this: the cost of changing the encoding
> >> would appear to outweigh the benefit. I'm not trying to claim the Linux
> >> RAID-6 implementation is optimal, but it is simple and appears to be
> >> fast enough that the math isn't the bottleneck.
> > 
> > Cost? Thank about how to get free grad student hours testing out things 
> > that you might or might not want to leverage on down the road :-)
> > 
> 
> Cost, yes, of changing an on-disk format.

Personally, I don't care about that -- I'm utterly uninterested in the
legacy RAID-6 setup where it pretends to be a normal disk. I think that
model is as fundamentally wrong as flash devices making the similar
pretence.

I'm only interested in what we can use directly within btrfs -- and
ideally I do want something which gives me an _arbitrary_ number of
redundant blocks, rather than limiting me to 2. But the legacy code is
good enough for now¹.

When I get round to wanting more, I was thinking of lifting something
like http://git.infradead.org/mtd-utils.git?a=blob;f=fec.c to start
with, and maybe hoping that someone cleverer will come up with something
better.

The less I have to deal with Galois Fields, the happier I'll be.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

¹ Well, kind of. The xor_blocks() function will silently screw you over
  if you ask it to handle more than 5 blocks at a time.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html