From: Bill Davidsen <davidsen@tmr.com>
To: Matthias Urlichs <matthias@urlichs.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Random bit flips - better data integrity needed [Was: Re: mismatch_count != 0 on multiple hosts]
Date: Tue, 13 Oct 2009 17:45:26 -0400 [thread overview]
Message-ID: <4AD4F4F6.7010506@tmr.com> (raw)
In-Reply-To: <h9abqh$e1m$2@ger.gmane.org>
Matthias Urlichs wrote:
> On Sat, 19 Sep 2009 12:10:34 -0400, Greg Freemyer wrote:
>
>
>> Specifically you could steal the second parity stripe from a raid 6
>> setup and replace it with this end-to-end data integrity checksum / crc.
>>
>
> If you're willing to add that kind of overhead, simply read all of the
> RAID6 stripes into memory and check whether they're consistent.
>
> If not, it's easy to decide (for RAID6) whether the data or the parity is
> wrong: simply check both P and Q. If only one is broken, fix it. If both
> are, correct the data according to P and check if Q is now correct. If
> so, fix it. Otherwise the only thing you can do is to fail the whole
> array, and to alert the operator that they have major hardware issues. :-/
>
> For RAID45, you can do the same, except that there's no way to fix any
> problems since you don't know whether data or parity is right. As the
> error may have crept in upon writing, rereading is of limited use.
>
> For RAID1 (and maybe even multipath), the same idea applies; add majority
> rule when you have more than two disks.
>
> Adding this kind of checking to the RAID456 driver should be rather easy
> for somebody who knows its internals. Its effect on read throughput is
> anyone's guess, of course.
>
To do this right requires forcing the data to the platter, then reading
it back (from the platter, not cache) and checking it. Preferably
reading with ECC off to catch marginal data. In the 60's there were
drives with read-after-write heads, but the data density was so low you
could sprinkle oxide on the platter and see data patterns. I can't see
doing it that way with "heads" any more, but when solid state becomes
more mainstream it becomes possible with useful transfer rates.
I have the feeling that someone had a patch to do that with a loopback
mount, but I can't find a pointer.
--
Bill Davidsen <davidsen@tmr.com>
Unintended results are the well-earned reward for incompetence.
prev parent reply other threads:[~2009-10-13 21:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-19 16:10 Random bit flips - better data integrity needed [Was: Re: mismatch_count != 0 on multiple hosts] Greg Freemyer
2009-09-20 9:36 ` John Robinson
2009-09-20 9:43 ` Majed B.
2009-09-20 15:30 ` Mario 'BitKoenig' Holbe
2009-09-20 21:55 ` Random bit flips - better data integrity needed Martin K. Petersen
2009-09-20 21:48 ` Martin K. Petersen
2009-09-22 11:18 ` Random bit flips - better data integrity needed [Was: Re: mismatch_count != 0 on multiple hosts] Matthias Urlichs
2009-10-13 21:45 ` Bill Davidsen [this message]
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=4AD4F4F6.7010506@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-raid@vger.kernel.org \
--cc=matthias@urlichs.de \
/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).