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@xxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
