From: Wolfgang Denk <wd@denx.de>
To: Chris Murphy <lists@colorremedies.com>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
linux-raid@vger.kernel.org
Subject: Re: Huge values of mismatch_cnt on RAID 6 arrays under Fedora 18
Date: Tue, 29 Jan 2013 00:23:16 +0100 [thread overview]
Message-ID: <20130128232316.7B60A203AD5@gemini.denx.de> (raw)
In-Reply-To: <ADB1B276-21F3-4006-A613-F979F931EDC3@colorremedies.com>
Dear Chris,
In message <ADB1B276-21F3-4006-A613-F979F931EDC3@colorremedies.com> you wrote:
>
> > Correct, these are 3 different machines.
>
> Too bad. Better to test first, than commit so many computers and arrays
> for such a major change.
In hindsight you are of course correct. But then, these are still not
really vitally critically systems, and I hve to admit that I did not
expect such kind of problems. I have installed a large number of
Fedora releases before (all of them since FC4 actually, on quite a
number of systems), and while there have always been some problems, I
never ran into something like this before.
> Unclear. If parity chunks are both wrong, then that means you
> effectively have partial RAID 0 depending on what parity chunks are
> correct or not. I'm not recommending this, but if you set one disk to
> faulty and started your file system and file tests again
if they're
> bad then indeed it's parity that's affected. If you don't get errors,
> then it indicates the test method is insufficient to locate the errors
> and it could still be data that's affected.
OK, I will keep this in mind. If needed, I can dedicate one of the
systems to even a destructive test without too much actual loss.
> It's a tenuous situation. It might be wise to pick a low priority
> computer for regression, and hopefully the problem gets better rather
> than worse. If the assumption is that the parity is bad, it needs to be
> recalculated with repair. If that goes well with tests and another check
> scrub, then it's better to get on with additional regressions sooner
> than later. Again in the meantime if you lost a drive, it could be a
> real mess if the raid starts to rebuild bad data from parity. Or even
> starts to write user data incorrectly too.
Well, I did this - the repair worked without errors, but it left again
a huge mismatch_cnt; raid6check on this array has not found any
problems so far - even though I see mismatch_cnt = 362731480
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
O Staat! Wie tief dir alle Besten fluchen! Du bist kein Ziel. Der
Mensch muß weiter suchen. - Christian Morgenstern
--
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:[~2013-01-28 23:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-27 19:26 Huge values of mismatch_cnt on RAID 6 arrays under Fedora 18 Wolfgang Denk
2013-01-27 19:45 ` Chris Murphy
2013-01-27 23:10 ` Wolfgang Denk
2013-01-27 20:05 ` Robin Hill
2013-01-27 23:11 ` Wolfgang Denk
2013-01-28 1:14 ` Phil Turmel
2013-01-28 1:42 ` Chris Murphy
2013-01-28 2:16 ` Chris Murphy
2013-01-28 6:43 ` Wolfgang Denk
2013-01-28 6:36 ` Wolfgang Denk
2013-01-28 7:00 ` Chris Murphy
2013-01-28 10:27 ` Wolfgang Denk
2013-01-28 6:27 ` Wolfgang Denk
2013-01-28 2:07 ` Brad Campbell
2013-01-28 6:39 ` Wolfgang Denk
2013-01-28 7:58 ` Dan Williams
2013-01-28 17:37 ` Piergiorgio Sartor
2013-01-28 18:12 ` Chris Murphy
2013-01-28 19:00 ` Wolfgang Denk
2013-01-28 19:10 ` Wolfgang Denk
2013-01-28 19:22 ` Piergiorgio Sartor
2013-01-28 20:19 ` Wolfgang Denk
2013-01-28 20:44 ` Piergiorgio Sartor
2013-01-28 22:47 ` Chris Murphy
2013-01-28 22:49 ` Chris Murphy
2013-01-28 23:03 ` Wolfgang Denk
2013-01-28 23:13 ` Chris Murphy
2013-01-28 23:31 ` Wolfgang Denk
2013-01-28 22:59 ` Wolfgang Denk
2013-01-28 23:07 ` Chris Murphy
2013-01-28 23:23 ` Wolfgang Denk [this message]
2013-01-28 23:42 ` Chris Murphy
2013-01-29 18:02 ` Roy Sigurd Karlsbakk
2013-01-29 18:28 ` Wolfgang Denk
2013-01-29 18:43 ` Roy Sigurd Karlsbakk
2013-01-29 17:49 ` Piergiorgio Sartor
2013-01-29 19:35 ` Paul Menzel
2013-01-29 20:18 ` Piergiorgio Sartor
2013-01-28 23:18 ` Wolfgang Denk
2013-01-29 17:57 ` Piergiorgio Sartor
2013-01-29 18:43 ` Wolfgang Denk
2013-01-29 20:24 ` Piergiorgio Sartor
2013-01-31 12:12 ` Wolfgang Denk
2013-01-31 17:14 ` Chris Murphy
2013-01-31 17:51 ` Piergiorgio Sartor
2013-01-31 18:36 ` Wolfgang Denk
2013-01-31 19:35 ` Chris Murphy
2013-01-31 19:46 ` Chris Murphy
2013-01-31 20:05 ` Wolfgang Denk
2013-01-31 20:41 ` Chris Murphy
2013-01-31 17:47 ` Piergiorgio Sartor
2013-01-28 19:18 ` Piergiorgio Sartor
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=20130128232316.7B60A203AD5@gemini.denx.de \
--to=wd@denx.de \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=piergiorgio.sartor@nexgo.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).