All of lore.kernel.org
 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 12:02:12 -0700	[thread overview]
Message-ID: <h3qhri$3di$2@ger.gmane.org> (raw)
In-Reply-To: h3qhmp$3di$1@ger.gmane.org

Alex Elsayed wrote:

> 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.

Whoops, got N (data) and M (checksum) backwards.




  reply	other threads:[~2009-07-17 19:02 UTC|newest]

Thread overview: 34+ 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-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
2009-07-17 19:02                     ` Alex Elsayed [this message]
2009-07-29 18:16                       ` H. Peter Anvin
2009-07-17 19:12                 ` Gregory Maxwell
2009-07-17 19:12                   ` Gregory Maxwell
2009-07-18 11:53                 ` David Woodhouse
2009-07-18 11:53                   ` David Woodhouse
2009-07-18 12:45                   ` H. Peter Anvin
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 12:49                     ` Ric Wheeler
2009-07-18 16:26                   ` Dan Williams
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='h3qhri$3di$2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.