From: NeilBrown <neilb@suse.de>
To: Alexander Lyakas <alex.bolshoy@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: raid1 repair: sync_request() aborts if one of the drives has bad block recorded
Date: Mon, 16 Jul 2012 13:37:53 +1000 [thread overview]
Message-ID: <20120716133753.1a34e149@notabene.brown> (raw)
In-Reply-To: <CAGRgLy6j3pEeXGXJbVc4Sz3gdShWWfaT7hyXnurgO-6N-_E_ZA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]
On Thu, 12 Jul 2012 18:38:43 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:
> Hi Neil,
> I am testing the following simple scenario:
> - RAID1 with two drives
> - First drive has a bad block marked in the bad block list
> - "repair" is triggered
Thanks for testing!!
>
> What is happening is that the code in raid1.c:sync_request() selects
> candidates for reading. If it encounters a bad block recorded, it
> skips this particular drive:
> if (is_badblock(rdev, sector_nr, good_sectors,
> &first_bad, &bad_sectors)) {
> if (first_bad > sector_nr)
> .../* we don't go here*/
> else {
> /* we go here*/
> bad_sectors -= (sector_nr - first_bad);
> if (min_bad == 0 ||
> min_bad > bad_sectors)
> min_bad = bad_sectors;
> }
> }
> if (sector_nr < first_bad) {
> /* we don't go here */
> ...
> But the second drive has no bad blocks recorded, so it is selected.
> So we end up with read_targets=1 and min_bad>0.
>
> Then the following code:
> if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) && read_targets > 0)
> /* extra read targets are also write targets */
> write_targets += read_targets-1;
> leaves write_targets=0
>
> Then the following code:
> if (write_targets == 0 || read_targets == 0) {
> /* There is nowhere to write, so all non-sync
> * drives must be failed - so we are finished
> */
> sector_t rv = max_sector - sector_nr;
> aborts the resync.
Oops.
>
> Is this the intended behavior? Because it looks like this bit does not
> take into account the bad-blocks existence.
> I am not sure about which logic would solve it, but something like "If
> we did not select a drive for reading because of bad blocks, and as a
> result we have only one read_target, and MD_RECOVERY_REQUESTED, then
> let's report only the bad block as skipped and not the whole drive".
> Something like that, but there are probably many cases I am not
> thinking about.
>
> What do you think?
I don't see that MD_RECOVERY_REQUESTED is really an issue is it?
We the wrong thing happen in any case where there just one device with no bad
block, and at least one device with a bad block. In that case we want to
skip forward by the number of bad blocks, not skip to the end of the array.
So this?
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 240ff31..c443f93 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2422,7 +2422,10 @@ static sector_t sync_request(struct mddev *mddev, sector_t sector_nr, int *skipp
/* There is nowhere to write, so all non-sync
* drives must be failed - so we are finished
*/
- sector_t rv = max_sector - sector_nr;
+ sector_t rv;
+ if (min_bad > 0)
+ max_sector = sector_nr + min_bad;
+ rv = max_sector - sector_nr;
*skipped = 1;
put_buf(r1_bio);
return rv;
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-07-16 3:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 15:38 raid1 repair: sync_request() aborts if one of the drives has bad block recorded Alexander Lyakas
2012-07-16 3:37 ` NeilBrown [this message]
2012-07-16 8:45 ` Alexander Lyakas
2012-07-17 1:17 ` NeilBrown
2012-07-17 13:17 ` Alexander Lyakas
2012-07-24 19:30 ` Alexander Lyakas
2012-07-31 2:11 ` NeilBrown
2012-07-31 5:56 ` Alexander Lyakas
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=20120716133753.1a34e149@notabene.brown \
--to=neilb@suse.de \
--cc=alex.bolshoy@gmail.com \
--cc=linux-raid@vger.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).