Linux RAID subsystem development
 help / color / mirror / Atom feed
From: "Leslie Rhorer" <lrhorer@satx.rr.com>
To: 'Mark Knecht' <markknecht@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: RE: Mismatches
Date: Sun, 2 Jan 2011 19:53:00 -0600	[thread overview]
Message-ID: <D6.53.07087.CFB212D4@cdptpa-omtalb.mail.rr.com> (raw)
In-Reply-To: <AANLkTimqKmegXCyPqeMn=fDVyPtNgyexUrC6QE4vRBzf@mail.gmail.com>

> -----Original Message-----
> From: Mark Knecht [mailto:markknecht@gmail.com]
> Sent: Sunday, January 02, 2011 7:23 PM
> To: lrhorer@satx.rr.com
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Mismatches
> 
> On Sun, Jan 2, 2011 at 5:10 PM, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> >
> >        OK, I asked this question here before, and I got no answer
> > whatsoever.  I wasn't too concerned previously, but now that I lost the
> > entire array the last time I tried to do a growth, I am truly concerned.
> > Would someone please answer my question this time, and perhaps point me
> > toward a resolution?  The monthly array check just finished on my main
> > machine.  For many months, this happened at the first of the month and
> > completed without issue and with zero mismatches.  As of a couple of
> months
> > ago, it started to report large numbers of mismatches.  It just
> completed
> > this afternoon with the following:
> >
> > RebuildFinished /dev/md0 mismatches found: 96614968
> >
> >        Now, 96,000,000 mismatches would seem to be a matter of great
> > concern, if you ask me.  How can there be any, really, when the entire
> array
> > - all 11T - was re-written just a few weeks ago?  How can I find out
> what
> > the nature of these mismatches is, and how can I correct them without
> > destroying the data on the array?  How can I look to prevent them in the
> > future?  I take it the monthly checkarray routine (which basically
> > implements ` echo check > /sys/block/md0/md/sync_action`) does not
> attempt
> > to fix any errors it finds?
> >
> >        I just recently found out md uses simple parity to try to
> maintain
> > the validity of the data.  I had always thought it was ECC.  With simple
> > parity it can be difficult or even impossible to tell which data member
> is
> > in error, given two conflicting members.  Where should I go from here?
>  Can
> > I use `echo repair > /sys/block/md0/md/sync_action` with impunity?
>  What,
> > exactly, will this do when it comes across a mismatch between one or
> more
> > members?
> >
> > RAID6 array
> > mdadm - v2.6.7.2
> > kernel 2.6.26-2-amd64
> 
> What commands are you running? Is it just the sync_action or other
> things in addition?

	Well, I haven't run anything at all, yet.  The checkarray script
runs once a month as a cron job on all the arrays and reports their health.
Until just a few months ago, all 8 arrays on the servers always reported
complete via e-mail with no reported mismatches.  Then a few months ago,
some of the arrays started report8ing mismatches.  I was of the impression
the checkarray routine would not ony report, but tryto fix mismatches.  This
seems to have been incorrect, perhaps.  In any case, while trying to grow
one of the arrays a couple of weeks or so ago, nearly every large file on
the main array of the main server was corrupted.  A few small files were
also corrupted.  I copied everything back over from the backup array, and
all seemed well, except that checkarray (during its normal cron run) is
still reporting massive numbers of mismatches on the array.

> It was my understanding when researching RAID6 last week that the two
> parity calculations are actually different. Only one of them is simple
> parity. The the other is part of an advanced math degree. ;-)
> (According to Wikipedia, not a definitive source for sure...)

	Well, that's encouraging, if true.  It doesn't explain how big
chunks of data in almost every large file got corrupted, though.

--
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

  reply	other threads:[~2011-01-03  1:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-03  1:10 Mismatches Leslie Rhorer
2011-01-03  1:22 ` Mismatches Mark Knecht
2011-01-03  1:53   ` Leslie Rhorer [this message]
2011-01-03  1:58     ` Mismatches Mark Knecht
2011-01-03  4:03       ` Mismatches Leslie Rhorer
2011-01-03  1:35 ` Mismatches Neil Brown
2011-01-03  3:12   ` Mismatches Leslie Rhorer

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=D6.53.07087.CFB212D4@cdptpa-omtalb.mail.rr.com \
    --to=lrhorer@satx.rr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=markknecht@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox