linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Elsayed <eternaleye@gmail.com>
To: linux-btrfs@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/4] md: Factor out RAID6 algorithms into lib/
Date: Fri, 17 Jul 2009 11:59:37 -0700	[thread overview]
Message-ID: <h3qhmp$3di$1@ger.gmane.org> (raw)
In-Reply-To: 4A609FA0.7060404@redhat.com

Ric Wheeler wrote:

> On 07/17/2009 11:49 AM, 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.
>>
>> -hpa
>>
> 
> Putting RAID6 behind us, we still might be interested in the other 
encodings 
> that are in:
> 
> "A Performance Evaluation and Examination of Open-Source Erasure Coding 
> Libraries For Storage"
> 
> http://www.cs.utk.edu/~plank/plank/papers/FAST-2009.html
> 
> since they give us even more flexibility....

Of course, there's also the fact that, using (essentially unchanged) the 
current code for Reed-Solomon coding, it's completely doable to have 
arbitrary NxM redundancy up to (N + M) < 256 disks (this limit is due to the 
current maximum of 8 for symsize [referred to as 'w' in the below paper] in 
rs_init. If increased to 16, the maximum number of disks would be 65535). 
It's also space-optimal for all combinations of N (checksum) and M (data).

http://www.cs.utk.edu/~plank/plank/papers/CS-96-332.html even describes an 
implementation _very_ similar to the current code, right down to using a 
table for the logarithm and inverse logarithm calculations.

Also, (referencing the earlier-posted paper comparing open-source coding 
techniques), Cauchy Reed-Solomon codes seem to maintain most of the benefits 
of the current system (including the ability to provide NxM redundancy, 
while still retaining the property of being space-optimal), with significant 
performance gains. It also provides an optimization for the RAID6 case, so 
once again the common case would get a benefit over less common cases (as 
with Mr. Anvin's RAID6 optimization in the current system)

However, I will have to dispute that the other methods provide more 
flexibility - Cauchy Reed-Solomon codes are at best a horizontal move there, 
and the other systems are restricted to (or at very least, far more 
effective in) RAID6 systems.



  reply	other threads:[~2009-07-17 18:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-13 14:11 [PATCH 1/4] md: Factor out RAID6 algorithms into lib/ David Woodhouse
2009-07-15 19:23 ` Dan Williams
2009-07-15 20:16   ` Chris Mason
2009-07-15 22:11     ` Dan Williams
2009-07-16 17:38   ` H. Peter Anvin
2009-07-17 14:22     ` Ric Wheeler
2009-07-17 15:20       ` H. Peter Anvin
2009-07-17 15:35         ` Ric Wheeler
2009-07-17 15:40           ` H. Peter Anvin
2009-07-17 15:47             ` Ric Wheeler
2009-07-17 15:49               ` H. Peter Anvin
2009-07-17 15:58                 ` Ric Wheeler
2009-07-17 18:59                   ` Alex Elsayed [this message]
2009-07-17 19:02                     ` Alex Elsayed
2009-07-29 18:16                       ` H. Peter Anvin
2009-07-17 19:12                 ` Gregory Maxwell
2009-07-18 11:53                 ` David Woodhouse
2009-07-18 12:45                   ` H. Peter Anvin
2009-07-18 18:50                     ` Alex Elsayed
2009-07-18 18:52                       ` Alex Elsayed
2009-07-29 18:20                         ` H. Peter Anvin
2009-07-18 12:49                   ` Ric Wheeler
2009-07-18 16:26                   ` Dan Williams
2009-07-18 18:42                     ` David Woodhouse
2009-07-18 20:04                       ` Dan Williams
2009-07-19 18:04                         ` David Woodhouse
2009-07-20  5:21                           ` H. Peter Anvin
2009-07-17 15:51               ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='h3qhmp$3di$1@ger.gmane.org' \
    --to=eternaleye@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).