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

[Ric Wheeler <rwheeler@redhat.com>]

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