linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Evans <mjevans1983@gmail.com>
To: Kasper Sandberg <postmaster@metanurb.dk>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Idea for new RAID type - background extended recovery information
Date: Sat, 12 Dec 2009 19:47:58 -0800	[thread overview]
Message-ID: <4877c76c0912121947m42a62a61y2b2a4a0a74b4d5e1@mail.gmail.com> (raw)
In-Reply-To: <1260602531.7209.10.camel@localhost>

On Fri, Dec 11, 2009 at 11:22 PM, Kasper Sandberg
<postmaster@metanurb.dk> wrote:
> On Wed, 2009-12-09 at 11:53 +0100, Mikael Abrahamsson wrote:
>> On Wed, 9 Dec 2009, Michael Evans wrote:
>
> while this could work, i would personally far rather see raid6 gain all
> the recovery/sanity options possible. raid6 has multiple copies of the
> same data, and as long as you have >2 copies, you can begin to look at
> all the data sets, and with a pretty good probability weed out the bad
> set.
>

While I would like to have a layer that any storage use, including
other raid levels, could reside within.  Imagine how much smarter
raid6 could be if it already knew in advance which stripes had gone
bad?  Or if files older than a few seconds could also gain an
additional 'bad sector' survival; allowing the loss of whatever normal
raid tolerances plus a bad sector or two.  It would not be required,
but I believe it would be a good way of adding assurance to long-term
storage segments.

I implore you to comment on the original suggestion, or my reply to
his reply as well.

  reply	other threads:[~2009-12-13  3:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09  9:06 Idea for new RAID type - background extended recovery information Michael Evans
2009-12-09 10:53 ` Mikael Abrahamsson
2009-12-10  0:45   ` Michael Evans
2009-12-12  7:22   ` Kasper Sandberg
2009-12-13  3:47     ` Michael Evans [this message]
2009-12-16 13:13       ` Goswin von Brederlow
2009-12-17  1:11         ` Michael Evans

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=4877c76c0912121947m42a62a61y2b2a4a0a74b4d5e1@mail.gmail.com \
    --to=mjevans1983@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=postmaster@metanurb.dk \
    --cc=swmike@swm.pp.se \
    /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).