From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: Marc MERLIN <marc@merlins.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Buffer I/O error on dev md5, logical block 7073536, async page read
Date: Sun, 30 Oct 2016 17:19:29 +0100 [thread overview]
Message-ID: <20161030161929.GA5582@metamorpher.de> (raw)
In-Reply-To: <20161030153857.GB28648@merlins.org>
On Sun, Oct 30, 2016 at 08:38:57AM -0700, Marc MERLIN wrote:
> (mmmh, but even so, rebuilding the spare should have cleared the bad blocks
> on at least one drive, no?)
If n+1 disks have bad blocks there's no data to sync over, so they just
propagate and stay bad forever. Or at least that's how it seemed to work
last time I tried it. I'm not familiar with bad blocks. I just turn it off.
As long as the bad block list is empty you can --update=no-bbl.
If everything else fails - edit the metadata or carefully recreate.
Which I don't recommend because you can go wrong in a hundred ways.
I don't remember if anyone ever had a proper solution to this.
It came up a couple of times on the list so you could search.
If you've replaced drives since, the drive that has been part of the array
the longest is probably the most likely to still have valid data in there.
That could be synced over to the other drives once the bbl is cleared.
It might not matter, you'd have to check with your filesystems if they
believe any files located there. (Filesystems sometimes maintain their
own bad block lists so you'd have to check those too.)
Regards
Andreas Klauer
next prev parent reply other threads:[~2016-10-30 16:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-30 2:16 Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30 9:33 ` Andreas Klauer
2016-10-30 15:38 ` Marc MERLIN
2016-10-30 16:19 ` Andreas Klauer [this message]
2016-10-30 16:34 ` Phil Turmel
2016-10-30 17:12 ` clearing blocks wrongfully marked as bad if --update=no-bbl can't be used? Marc MERLIN
2016-10-30 17:16 ` Marc MERLIN
2016-11-04 18:18 ` Marc MERLIN
2016-11-04 18:22 ` Phil Turmel
2016-11-04 18:50 ` Marc MERLIN
2016-11-04 18:59 ` Roman Mamedov
2016-11-04 19:31 ` Roman Mamedov
2016-11-04 20:02 ` Marc MERLIN
2016-11-04 19:51 ` Marc MERLIN
2016-11-07 0:16 ` NeilBrown
2016-11-07 1:13 ` Marc MERLIN
2016-11-07 3:36 ` Phil Turmel
2016-10-30 18:56 ` [ LR] Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds TomK
2016-10-30 19:16 ` TomK
2016-10-30 20:13 ` Andreas Klauer
2016-10-30 21:08 ` TomK
2016-10-31 19:29 ` Wols Lists
2016-11-01 2:40 ` TomK
2016-10-30 16:43 ` Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30 17:02 ` Andreas Klauer
2016-10-31 19:24 ` Wols Lists
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=20161030161929.GA5582@metamorpher.de \
--to=andreas.klauer@metamorpher.de \
--cc=linux-raid@vger.kernel.org \
--cc=marc@merlins.org \
/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).