linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
	Eyal Lebedinsky <eyal@eyal.emu.id.au>
Cc: list linux-raid <linux-raid@vger.kernel.org>
Subject: Re: using the raid6check report
Date: Sun, 8 Jan 2017 20:52:40 +0000	[thread overview]
Message-ID: <5872A698.7000009@youngman.org.uk> (raw)
In-Reply-To: <20170108174010.GA3699@lazy.lzy>

On 08/01/17 17:40, Piergiorgio Sartor wrote:
> On Fri, Dec 23, 2016 at 11:56:34AM +1100, Eyal Lebedinsky wrote:
>> > From time to time I get non-zero mismatch_count in the weekly scrub. The way I handle
>> > it is to run a check around the stripe (I have a background job printing the mismatch
>> > count and /proc/mdstat regularly) which should report the same count.
>> > 
>> > I now drill into the fs to find which files use this area, deal with them and delete
>> > the bad ones. I then run a repair on that small area.
>> > 
>> > I now found about raid6check which can actually tell me which disk holds the bad data.
>> > This is something raid6 should be able to do assuming a single error.
>> > Hoping it is one bad disk, the simple solution now is to recover the bad stripe on
>> > that disk.
>> > 
>> > Will a 'repair' rewrite the bad disk or just create fresh P+Q which may just make the
>> > bad data invisible to a 'check'? I recall this being the case in the past.
> "repair" should fix the data which is assumed
> to be wrong.
> It should not simply correct P+Q, but really
> find out which disk is not OK and fix it.
> 
Having just looked at the man page and the source to raid6check as found
online ...

"man raid6check" says that it does not write to the disk. Looking at the
source, it appears to have code that is intended to write to the disk
and repair the stripe. So what's going on?

I can add it to the wiki as a little programming project, but it would
be nice to know the exact status of things - my raid-fu isn't good
enough at present to read the code and work out what's going on.

It would be nice to be able to write "parity-check" or somesuch to
sync_action, and then for raid5 it would check and update parity, or
raid6 it would check and correct data/parity.

Cheers,
Wol

  parent reply	other threads:[~2017-01-08 20:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-23  0:56 using the raid6check report Eyal Lebedinsky
2017-01-08 17:40 ` Piergiorgio Sartor
2017-01-08 20:36   ` Eyal Lebedinsky
2017-01-08 20:46     ` Piergiorgio Sartor
2017-01-08 21:06       ` Wols Lists
2017-01-08 21:20         ` Eyal Lebedinsky
2017-01-08 21:43         ` Piergiorgio Sartor
2017-01-08 20:52   ` Wols Lists [this message]
2017-01-08 21:41     ` Piergiorgio Sartor
2017-01-08 22:39       ` NeilBrown
2017-01-09  0:32         ` Eyal Lebedinsky
2017-01-09  1:56           ` NeilBrown
2017-01-09  2:13             ` Eyal Lebedinsky

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=5872A698.7000009@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=eyal@eyal.emu.id.au \
    --cc=linux-raid@vger.kernel.org \
    --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).