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

["H. Peter Anvin" <hpa@zytor.com>]

David Woodhouse wrote:
> 
> 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.
> 

Well, if you want something with more than 2-block redundancy you need 
something other than the existing RAID-6 code which, as you know, is a 
special case of general Reed-Solomon coding that I happen to have spent 
a lot of time optimizing.  The FEC code is not optimized at all if I can 
tell, and certainly doesn't use SSE in any way -- never mind the GF 
accelerators that are starting to appear.  That doesn't mean it 
*couldn't*, just that noone has done the work to either implement it or 
prove it can't be done.

Either way, perhaps the Plank paper that Rik pointed to could be useful 
as a starting point; it's probably worth taking their performance 
numbers with a *major* grain of salt: their implementation of RAID-6 
"RS-Opt" which is supposed to be equivalent to my code performs at
400 MB/s, which is less than Pentium III-era performance of the real 
world code (they compare not to real code but to their own 
implementation in Java, called "Jerasure".)  Implementability using real 
array instruction sets is key to decent performance.

	-hpa
--
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