From: Redeeman <redeeman@metanurb.dk>
To: "Michał Przyłuski" <mikylie@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: detection/correction of corruption with raid6
Date: Fri, 12 Dec 2008 16:31:24 +0100 [thread overview]
Message-ID: <1229095884.16555.144.camel@localhost> (raw)
In-Reply-To: <6c4602af0812051330o4220cbf1g8b969cd4b9843d3a@mail.gmail.com>
On Fri, 2008-12-05 at 22:30 +0100, Michał Przyłuski wrote:
> Hi,
>
> 2008/12/5 Redeeman <redeeman@metanurb.dk>:
> > On Fri, 2008-12-05 at 16:09 -0500, Justin Piszcz wrote:
> >>
> >> On Fri, 5 Dec 2008, Redeeman wrote:
> >>
> >> > On Fri, 2008-12-05 at 16:02 -0500, Justin Piszcz wrote:
> >> >>
> >> >> On Fri, 5 Dec 2008, Redeeman wrote:
> >> >>
> >> >>> Hello.
> >> >>>
> >> >>> I was looking at the PDFs linked to from the wiki, and found this:
> >> >>> http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
> >> >>>
> >> >>> More specifically, section 4, starting on page 8.
> >> >>>
> >> >>> Am I understanding this correctly, in that with raid6, linux is capable
> >> >>> of detecting if the content on 1 disk is corrupted, and reconstruct it
> >> >>> from the remaining disks?
> >> >>
> >> >> I ran md/raid6 for awhile, do you mean remap the bad sector on the fly?
> >> >> Linux/md raid does not do this afaik.
> >> >
> >> > No, i mean, if one disk does silent corruption
> >>
> >> What would the error look like? Both md/Linux & in the 3ware manual
> >> recommend you run a 'check' across the raid at least once a week
> >> (3ware/raid-verify) and md/Linux in Debian runs a check once a month I
> >> believe to eliminate these issues.
> >>
> >> If you are asking whether a read error of a latent sector from the one
> >> disk will result it reading the data from the second disk that is a good
> >> question.
> >
> > im asking, if one disk in a raid6 setup suddenly decides to flip a few
> > bits in some bytes, will it be able to detect that in a scan, and
> > correct it? i cant see how it can do it on raid5, but maybe raid6?
>
> No, not really.
> I've been investigating silent corruption for a quite a while now, and
> it looks more or less like this.
> During a "check" action it'll be detected. During normal operation -
> it won't be detected.
> Normal (non-degraded) raid5/6 reads don't read parity (or Q syndrome),
> they just read data. So they have no idea that something went bad.
> Now, worse news is that you cannot really fix it automagically, even
> after detecting by a "check" procedure. A "repair" will overwrite
> parity and Q syndrome, with new values (new = calculated from what it
> seems to be data blocks).
>
> It is possible (by the theory of Q syndrome, per the article you
> linked) to detect which drive is doing a silent corruption with raid6
> (and with some extra assumption, that just one drive is doing that).
> But it's not implemented.
thats a shame, it seems like a KILLER feature, but i guess its not too
simple to do, or it would have been done already :)
>
> Greets,
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-12-12 15:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-05 21:00 detection/correction of corruption with raid6 Redeeman
2008-12-05 21:02 ` Justin Piszcz
2008-12-05 21:06 ` Redeeman
2008-12-05 21:09 ` Justin Piszcz
2008-12-05 21:12 ` Redeeman
2008-12-05 21:17 ` Justin Piszcz
2008-12-05 21:30 ` Michał Przyłuski
2008-12-05 22:12 ` Peter Rabbitson
2008-12-05 22:26 ` Michał Przyłuski
2008-12-05 22:43 ` Greg Freemyer
2008-12-06 0:39 ` Roger Heflin
2008-12-12 15:31 ` Redeeman [this message]
2008-12-16 2:33 ` Neil Brown
2008-12-16 6:33 ` Redeeman
2008-12-16 7:59 ` Mattias Wadenstein
2008-12-16 22:20 ` Chris Worley
-- strict thread matches above, loose matches on Subject: below --
2008-12-16 21:58 Piergiorgio Sartor
2008-12-16 22:25 ` Redeeman
2008-12-17 21:52 ` Piergiorgio Sartor
2008-12-19 4:39 ` Neil Brown
2008-12-19 5:38 ` Redeeman
2008-12-17 14:48 ` Bill Davidsen
2008-12-17 15:50 ` David Lethe
[not found] ` <494960E8.8020407@tmr.com>
2008-12-17 21:47 ` David Lethe
2008-12-19 8:40 piergiorgio.sartor
2008-12-19 13:10 ` Redeeman
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=1229095884.16555.144.camel@localhost \
--to=redeeman@metanurb.dk \
--cc=linux-raid@vger.kernel.org \
--cc=mikylie@gmail.com \
/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.