On 07/18/2009 07:53 AM, David Woodhouse wrote:
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.
I think that we are generally fine with the RAID5/6 support given a
small number of drives. The fancier erasure encodings are much more
interesting when you have a large number of drives - for example, we
just ordered 4 shelves of SATA drives (15/shelf) that will be driven by
a single server. You can certainly imagine profiling a lot of
interesting variations with that many things to play with.
Ric
--
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
