From: piergiorgio.sartor@nexgo.de
To: neilb@suse.de
Cc: linux-raid@vger.kernel.org
Subject: Re: detection/correction of corruption with raid6
Date: Fri, 19 Dec 2008 09:40:46 +0100 (CET) [thread overview]
Message-ID: <33141855.1229676046422.JavaMail.ngmail@webmail11.arcor-online.net> (raw)
Hi,
thanks for the answer.
I've still some comments on the topic, see below.
> Suppose we agree that bit flips don't happen (undetected) on drive
> media. But that bit flips can happen elsewhere (memory. IO Buss
> etc).
>
> And then suppose we discover that a bit-flip has happened. What does
> that tell us?
> Maybe it tells us that our hardware is dodgey. So it cannot be
> trusted to reliably do anything we tell it. So maybe we shouldn't
> tell it to do anything. ??
Maybe I should try to clarify the concept.
There are *two* use cases.
One is the "check" and one is the "repair".
As I already wrote, I do agree that "repair" needs some deeper
thinking. It is easy to see cases where it could produce more
damages.
The "check" case is another story.
In case of RAID-6 I would like, as RFE, to have in the logs some
report on which "drive" or "data path" the mismatch occurs, when
detectable.
So, if the mismatch count says there are 1024 mismatches, then
would be nice to know if they belong all to the same drive or not.
In this case, it would be possible to fail/remove that one and
check the hardware (change drive/cable/connector/etc.).
Ideally, at the end of the "check", the log should report how
many mismatches, how many are "undeterminable" (multiple
drive), how many could belong to a specific drive.
This will help to to diagnose a problem, maybe reported by
the CRC in the filesystem.
This is for the "check", about the "repair", the only possible
change I could see is to offer the user, and we could check
in this mailing list how many would like to have the possibility,
the option to "reset the parity" of the array or "recalculate the
data", with the warning that the second one can do more
damage than already has.
Conclusion, for me, is that the "check" should be more
clever, with RAID-6, and "repair/resync" *might* be more
flexible (with warnings).
I take the opportunity to wish you all Merry Christmas
and Happy New Year.
bye,
--
pg
Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
--
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 reply other threads:[~2008-12-19 8:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-19 8:40 piergiorgio.sartor [this message]
2008-12-19 13:10 ` detection/correction of corruption with raid6 Redeeman
-- 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-05 21:00 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
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
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=33141855.1229676046422.JavaMail.ngmail@webmail11.arcor-online.net \
--to=piergiorgio.sartor@nexgo.de \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.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).