From: Marc MERLIN <marc@merlins.org>
To: Phil Turmel <philip@turmel.org>
Cc: Sarah Newman <srn@prgmr.com>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
Date: Mon, 6 Jun 2016 21:51:22 -0700 [thread overview]
Message-ID: <20160607045122.GL12382@merlins.org> (raw)
In-Reply-To: <57561B38.1070402@turmel.org>
On Mon, Jun 06, 2016 at 08:54:16PM -0400, Phil Turmel wrote:
> Repair doesn't even read the parity (and Q syndrome) blocks if it
> doesn't need them. It unconditionally recomputes and writes parity (and
> Q) blocks.
I see. So if it happens to rewrite a parity block that was unreadable
but that it didn't have to read, I won't even know it was unreadable to
start with (but only one change out of n of that happening in raid5)
> Both processes will compute and rewrite a block that reports a read error.
> > https://www.thomas-krenn.com/en/wiki/Mdadm_checkarray#Check_vs._Repair
> >
> > Or are you saying that check after getting a read error from one drive,
> > would not rewrite the bad block on that drive? I thought it did...
>
> They both do.
Thanks for confirming.
> Both processes only apply to the actual data area of each member device,
> which is usually substantially less than the whole disk. Both processes
> will read or write (or both) every data area sector.
Mmmh, so it keeps track of how much of my block device is used by
filesystem blocks and skips the rest? I didn't know that.
> Sectors that haven't ever been deliberately written and aren't read by
> normal mdadm processes are often the first to pop up in disk
> self-diagnostics. If you look at the sector offsets in the SMART data,
> I bet you find they're all outside the area mdadm is using.
Got it.
> > Whereas badblocks forced an unconditional rewrite of all blocks, and forced
> > the drive to re-allocate those "weak" blocks, even though it was able to
> > read them.
>
> Probably not. It got 'em because it wasn't limited to the data area.
Right, I understand now, good to know.
So I'll use badblocks next time I have this issue.
Thanks for clearing this up for me.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2016-06-07 4:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 17:41 Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did Marc MERLIN
2016-06-06 19:10 ` Sarah Newman
2016-06-06 22:44 ` Marc MERLIN
2016-06-07 0:54 ` Phil Turmel
2016-06-07 4:51 ` Marc MERLIN [this message]
2016-06-07 13:04 ` Phil Turmel
2016-06-07 13:56 ` Mikael Abrahamsson
2016-06-07 14:04 ` Marc MERLIN
2016-06-08 1:39 ` Brad Campbell
2016-06-08 12:24 ` Phil Turmel
2016-06-07 5:35 ` Roman Mamedov
2016-06-07 13:57 ` Andreas Klauer
2016-06-07 14:14 ` Phil Turmel
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=20160607045122.GL12382@merlins.org \
--to=marc@merlins.org \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.org \
--cc=srn@prgmr.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;
as well as URLs for NNTP newsgroup(s).