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-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
