All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Marc MERLIN <marc@merlins.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: Tue, 7 Jun 2016 09:04:58 -0400	[thread overview]
Message-ID: <5756C67A.2040109@turmel.org> (raw)
In-Reply-To: <20160607045122.GL12382@merlins.org>

On 06/07/2016 12:51 AM, Marc MERLIN wrote:
> On Mon, Jun 06, 2016 at 08:54:16PM -0400, Phil Turmel wrote:

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

No, it doesn't keep track of anything the filesystem does.  Look at the
mdadm -E report for one of you member devices -- it shows the location
of the superblock, the start location and size of the data area, and
possibly information about the optional bitmap or bad block table.
Areas outside the data area are not touched by check or repair scrubs.

> Right, I understand now, good to know.
> So I'll use badblocks next time I have this issue.

Or just ignore them.  You aren't using them, so they can't hurt you.
However, do look at the sector numbers in the SMART reports to make sure
they aren't in the data area.  (If you aren't using the whole disk for
mdadm, be sure to adjust for the partition start sector.)  If they *are*
in the data area, watch dmesg while scrubbing to see what's really
happening.

Phil

  reply	other threads:[~2016-06-07 13:04 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
2016-06-07 13:04         ` Phil Turmel [this message]
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=5756C67A.2040109@turmel.org \
    --to=philip@turmel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=marc@merlins.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.