linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-raid@vger.kernel.org
Subject: Re: Adding Reed-Solomon Personality to MD, need help/advice
Date: Thu, 29 Dec 2005 10:40:33 -0800 (PST)	[thread overview]
Message-ID: <dp1aj1$su0$1@terminus.zytor.com> (raw)
In-Reply-To: dlsh2c$2h0$1@sea.gmane.org

Followup to:  <dlsh2c$2h0$1@sea.gmane.org>
By author:    "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
In newsgroup: linux.dev.raid
>
> Hello,
> 
> Nathan Lewis <nathapl@cs.okstate.edu> wrote:
> > As part of my Master's thesis, I am working on adding a Reed-Solomon 
> > personality to the existing linux RAID structure and I would like some 
> 
> Is there any progress in implementing a generic Reed-Solomon personality
> in MD since this mail from 31 Jan 2004?
> Regarding the intention-question... for me, personally, it would be the
> logical step inbetween raid5 resp. raid6 with survival of 1 resp. 2
> simultaneous disk failures and raid10 with survival of n/2 simultaneous
> disk failures. RaidRS would give users the chance to configure
> redundancy and thus survivability exactly on their demands.
> This would especially make sense when I see the raid5 configurations
> with 14 and more devices which some users refer to on this list.
> To be honest, I was thinking about such a personality myself, too, and
> then was crawling the list's archive.
> 

It's not really in-between; generic RS RAID would be many times slower
than either; however, unlike raid10 it could survive *any* m failures
where m is the number of redundancy drives.

The fundamental problem is that generic RS requires table lookups even
in the common case, whereas RAID-6 uses shortcuts to substantially
speed up the computation in the common case.  RAID-6 is an important
corner of the problem space, since it deals with the unfortunately
fairly common problem of "disk failure discovered during recovery"
with RAID-5.

That doesn't mean there couldn't be a problem space where it would
make sense (in fact, on the contrary), but it's still a substantial
engineering effort that would have to be justified.

Heck, I might even be persuaded to look for generic RS shortcuts if
someone tempted me enough...

	-hpa


  reply	other threads:[~2005-12-29 18:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-31  6:59 Adding Reed-Solomon Personality to MD, need help/advice Nathan Lewis
2004-01-31  7:20 ` H. Peter Anvin
2004-01-31 10:53 ` Neil Brown
2004-01-31 18:56   ` Nathan Lewis
2004-02-13  4:35   ` Nathan Lewis
2004-02-13 14:18     ` Ming Zhang
2004-02-13 20:54       ` Nathan Lewis
2005-11-21 13:11 ` Mario 'BitKoenig' Holbe
2005-12-29 18:40   ` H. Peter Anvin [this message]
2005-12-29 19:23     ` Bill Rugolsky Jr.
2005-12-29 19:54     ` Jeff Breidenbach
2005-12-29 21:14       ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2006-01-03 22:08 Bailey, Scott
2006-01-05  0:23 ` Jeff Breidenbach
2006-01-08 17:49 ` Bill Davidsen

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='dp1aj1$su0$1@terminus.zytor.com' \
    --to=hpa@zytor.com \
    --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).