From: NeilBrown <neilb@suse.com>
To: Shaohua Li <shli@kernel.org>, George Rapp <george.rapp@gmail.com>
Cc: Linux-RAID <linux-raid@vger.kernel.org>,
Matthew Krumwiede <matt.krumwiede@me.com>,
Jes.Sorensen@gmail.com
Subject: Re: Reshape stalled at first badblock location (was: RAID 5 --assemble doesn't recognize all overlays as component devices)
Date: Fri, 03 Mar 2017 11:27:47 +1100 [thread overview]
Message-ID: <8760jrnr0c.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170221175801.wt64t2tzcvg3sfmc@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
On Tue, Feb 21 2017, Shaohua Li wrote:
>
> Add Neil and Jes.
>
> Yes, there were similar reports before. When reshape finds nadblocks, the
> reshape will do an infinite loop without any progress. I think there are two
> things we need to do:
>
> - Make reshape more robust. Maybe reshape should bail out if badblocks found.
> - Add an option in mdadm to force reset badblocks
The second of these is already possible
Commit: 6dd16dac4001 ("Add --update=force-no-bbl.")
It isn't documented though, and only works during "assemble", not on an
active array.
Writing to the "bad" blocks should remove the "bad" status. It would be
nice if mdadm could locate the bad blocks, map them to array blocks,
trigger a limited "resync" if there are any good copies, or write zeros
if there aren't.
And yes; reshape should be more robust... if only we had a pool of
developers, eager to work on these problems :-)
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2017-03-03 0:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 22:18 Reshape stalled at first badblock location (was: RAID 5 --assemble doesn't recognize all overlays as component devices) George Rapp
2017-02-21 9:51 ` Tomasz Majchrzak
2017-02-21 17:58 ` Shaohua Li
2017-02-22 1:12 ` George Rapp
2017-02-22 16:17 ` Phil Turmel
2017-02-22 18:39 ` George Rapp
2017-03-03 0:27 ` NeilBrown [this message]
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=8760jrnr0c.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=Jes.Sorensen@gmail.com \
--cc=george.rapp@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=matt.krumwiede@me.com \
--cc=shli@kernel.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).