| Message ID | 20230522115449.2203939-3-linan666@huaweicloud.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1400269vqo;
Mon, 22 May 2023 05:13:13 -0700 (PDT)
X-Google-Smtp-Source:
ACHHUZ6U0Ky86To9Qd+yJ9fc50IMBUluc8QAKSsw39fIkqHeVpQg36CXPGecrdBmy8xCbWdq1oAM
X-Received: by 2002:a17:90b:3106:b0:253:3cfa:e310 with SMTP id
gc6-20020a17090b310600b002533cfae310mr9930015pjb.19.1684757592797;
Mon, 22 May 2023 05:13:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1684757592; cv=none;
d=google.com; s=arc-20160816;
b=cK/tVMEEsOzWgPKAJRfljgsfNSJCpdNzNsD39BhHkLY/EY4w00j0R6/1XWbewffV0O
bThNSgC+hBsd1oMqtUeIpmoLp5yelSwpQ/5bSmuoVaY+l8DtWQcuRoTha1MNT48ZZh6w
VeXtXFGhPRqyy+nP8Ol3SVx6ymPM+y+7Gna0sLDWHkNwQnbvZD2fiRHTA/fIXnjW656H
ujravbV182j/H0u/UXtuEpMLqvLi2Q+M8Kk9GLbJNLka2G7E8YR+9yEm1RBzW6iiskHN
Gkb4SSIatN+ekiPdggsGuoptxRF4vrPhwGDxm8XNoIVi9r9gPgjSVxuVnCDIfwia+gTE
HEcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:references:in-reply-to:message-id:date:subject:cc:to:from;
bh=dxePFlnKTE2+mFcGDaqKOwIttKERZlpZdHDe7dscF0E=;
b=svl36qUhq7AwBlvNX0bprN5f9FM78dm0rdkKIQ5nI5gMdnIA4wr67rP07ew9siJS3I
38+H3HxOGObT738IvKt6Ydgl0CLuk8dEld0OlT3q2VMWAjrj9YMhdGNAv5/u0qJVih8q
g4Pum/e/vygtGCC2gWhgyhw3VFtXZT69NPapaJQI80o7ye7jeuCKCDPHXMCPZVTV4qDU
JC9BsvZMucrgF0whqTZi7jijSkmZxh7iqVeqS4D9EZM5GZgZ0VM5C1hNMJB331wsQif2
pgpIPEoK/OpinEVRHf7x6vJvPQLSksAt9fIM5TW+6+UBDzfrdwnWTpHI9uvvDrWarGad
9AKw==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
d29-20020a63735d000000b0052c2904e37dsi4540718pgn.362.2023.05.22.05.12.58;
Mon, 22 May 2023 05:13:12 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S232676AbjEVL4f (ORCPT <rfc822;cscallsign@gmail.com> + 99 others);
Mon, 22 May 2023 07:56:35 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34072 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S233202AbjEVL41 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Mon, 22 May 2023 07:56:27 -0400
Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 684EC93;
Mon, 22 May 2023 04:56:24 -0700 (PDT)
Received: from mail02.huawei.com (unknown [172.30.67.153])
by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id
4QPws05YqSz4f426c;
Mon, 22 May 2023 19:56:20 +0800 (CST)
Received: from huaweicloud.com (unknown [10.175.127.227])
by APP4 (Coremail) with SMTP id gCh0CgBXwLNiWGtk2XrkJw--.28031S6;
Mon, 22 May 2023 19:56:21 +0800 (CST)
From: linan666@huaweicloud.com
To: song@kernel.org, shli@fb.com, allenpeng@synology.com,
alexwu@synology.com, bingjingc@synology.com, neilb@suse.de
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
linan122@huawei.com, yukuai3@huawei.com, yi.zhang@huawei.com,
houtao1@huawei.com, yangerkun@huawei.com
Subject: [PATCH 2/3] md/raid10: fix incorrect done of recovery
Date: Mon, 22 May 2023 19:54:48 +0800
Message-Id: <20230522115449.2203939-3-linan666@huaweicloud.com>
X-Mailer: git-send-email 2.31.1
In-Reply-To: <20230522115449.2203939-1-linan666@huaweicloud.com>
References: <20230522115449.2203939-1-linan666@huaweicloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: gCh0CgBXwLNiWGtk2XrkJw--.28031S6
X-Coremail-Antispam: 1UD129KBjvJXoW7AFyktF13tF1rZF43Zw48Xrb_yoW8ZFy7pa
n3JFZ3t398W3yfJ3WDAryUXFWFy348Ja42krsrW34j9r90qrWDZFWfXFW8XF9rWF1FqayY
qw4DJrW5uFyxKaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2
9KBjDU0xBIdaVrnRJUUUm0b4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2
6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUXw
A2048vs2IY020Ec7CjxVAFwI0_Xr0E3s1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS
w2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV
W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v2
6rxl6s0DM2vYz4IE04k24VAvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrV
ACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWU
JVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2
ka0xkIwI1lw4CEc2x0rVAKj4xxMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j
6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7
AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE
2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcV
C2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVj
vjDU0xZFpf9x07UNAwxUUUUU=
X-CM-SenderInfo: polqt0awwwqx5xdzvxpfor3voofrz/
X-CFilter-Loop: Reflected
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS,
SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1766596377866649130?=
X-GMAIL-MSGID: =?utf-8?q?1766596377866649130?=
|
| Series |
raid10 bugfix
|
|
Commit Message
Li Nan
May 22, 2023, 11:54 a.m. UTC
From: Li Nan <linan122@huawei.com> Recovery will go to giveup and let chunks_skipped++ in raid10_sync_request() if there are some bad_blocks, and it will return max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and data is inconsistent but user think recovery is done, it is wrong. Fix it by set mirror's recovery_disabled and spare device shouln't be added to here. Signed-off-by: Li Nan <linan122@huawei.com> --- drivers/md/raid10.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
Comments
Hi, 在 2023/05/22 19:54, linan666@huaweicloud.com 写道: > From: Li Nan <linan122@huawei.com> > > Recovery will go to giveup and let chunks_skipped++ in > raid10_sync_request() if there are some bad_blocks, and it will return > max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and > data is inconsistent but user think recovery is done, it is wrong. > > Fix it by set mirror's recovery_disabled and spare device shouln't be > added to here. > > Signed-off-by: Li Nan <linan122@huawei.com> > --- > drivers/md/raid10.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c > index e21502c03b45..70cc87c7ee57 100644 > --- a/drivers/md/raid10.c > +++ b/drivers/md/raid10.c > @@ -3303,6 +3303,7 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, > int chunks_skipped = 0; > sector_t chunk_mask = conf->geo.chunk_mask; > int page_idx = 0; > + int error_disk = -1; > > /* > * Allow skipping a full rebuild for incremental assembly > @@ -3386,7 +3387,18 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, > return reshape_request(mddev, sector_nr, skipped); > > if (chunks_skipped >= conf->geo.raid_disks) { > - /* if there has been nothing to do on any drive, > + pr_err("md/raid10:%s: %s fail\n", mdname(mddev), > + test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ? "resync" : "recovery"); Line exceed 80 columns, and following. > + if (error_disk >= 0 && !test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) { Resync has the same problem, right? Thanks, Kuai > + /* > + * recovery fail, set mirrors.recovory_disabled, > + * device shouldn't be added to there. > + */ > + conf->mirrors[error_disk].recovery_disabled = mddev->recovery_disabled; > + return 0; > + } > + /* > + * if there has been nothing to do on any drive, > * then there is nothing to do at all.. > */ > *skipped = 1; > @@ -3640,6 +3652,8 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, > mdname(mddev)); > mirror->recovery_disabled > = mddev->recovery_disabled; > + } else { > + error_disk = i; > } > put_buf(r10_bio); > if (rb2) >
On Mon, May 22, 2023 at 6:54 AM Yu Kuai <yukuai1@huaweicloud.com> wrote: > > Hi, > > 在 2023/05/22 19:54, linan666@huaweicloud.com 写道: > > From: Li Nan <linan122@huawei.com> > > > > Recovery will go to giveup and let chunks_skipped++ in > > raid10_sync_request() if there are some bad_blocks, and it will return > > max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and > > data is inconsistent but user think recovery is done, it is wrong. > > > > Fix it by set mirror's recovery_disabled and spare device shouln't be > > added to here. > > > > Signed-off-by: Li Nan <linan122@huawei.com> > > --- > > drivers/md/raid10.c | 16 +++++++++++++++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c > > index e21502c03b45..70cc87c7ee57 100644 > > --- a/drivers/md/raid10.c > > +++ b/drivers/md/raid10.c > > @@ -3303,6 +3303,7 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, > > int chunks_skipped = 0; > > sector_t chunk_mask = conf->geo.chunk_mask; > > int page_idx = 0; > > + int error_disk = -1; > > > > /* > > * Allow skipping a full rebuild for incremental assembly > > @@ -3386,7 +3387,18 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, > > return reshape_request(mddev, sector_nr, skipped); > > > > if (chunks_skipped >= conf->geo.raid_disks) { > > - /* if there has been nothing to do on any drive, > > + pr_err("md/raid10:%s: %s fail\n", mdname(mddev), > > + test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ? "resync" : "recovery"); > > Line exceed 80 columns, and following. If it makes the code look better, such as in this case, it is OK to have lines longer than 80 columns. Thanks, Song > > + if (error_disk >= 0 && !test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) { >
在 2023/5/22 21:54, Yu Kuai 写道: > Hi, > > 在 2023/05/22 19:54, linan666@huaweicloud.com 写道: >> From: Li Nan <linan122@huawei.com> >> >> Recovery will go to giveup and let chunks_skipped++ in >> raid10_sync_request() if there are some bad_blocks, and it will return >> max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and >> data is inconsistent but user think recovery is done, it is wrong. >> >> Fix it by set mirror's recovery_disabled and spare device shouln't be >> added to here. >> >> Signed-off-by: Li Nan <linan122@huawei.com> >> --- >> drivers/md/raid10.c | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c >> index e21502c03b45..70cc87c7ee57 100644 >> --- a/drivers/md/raid10.c >> +++ b/drivers/md/raid10.c >> @@ -3303,6 +3303,7 @@ static sector_t raid10_sync_request(struct mddev >> *mddev, sector_t sector_nr, >> int chunks_skipped = 0; >> sector_t chunk_mask = conf->geo.chunk_mask; >> int page_idx = 0; >> + int error_disk = -1; >> /* >> * Allow skipping a full rebuild for incremental assembly >> @@ -3386,7 +3387,18 @@ static sector_t raid10_sync_request(struct >> mddev *mddev, sector_t sector_nr, >> return reshape_request(mddev, sector_nr, skipped); >> if (chunks_skipped >= conf->geo.raid_disks) { >> - /* if there has been nothing to do on any drive, >> + pr_err("md/raid10:%s: %s fail\n", mdname(mddev), >> + test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ? "resync" >> : "recovery"); > > Line exceed 80 columns, and following. >> + if (error_disk >= 0 && !test_bit(MD_RECOVERY_SYNC, >> &mddev->recovery)) { > > Resync has the same problem, right? > Yes. But I have no idea to fix it. md_error disk nor set recovery_disabled is a good solution. So, just print error message now. Do you have any ideas?
Hi, 在 2023/05/25 22:00, Li Nan 写道: > > > 在 2023/5/22 21:54, Yu Kuai 写道: >> Hi, >> >> 在 2023/05/22 19:54, linan666@huaweicloud.com 写道: >>> From: Li Nan <linan122@huawei.com> >>> >>> Recovery will go to giveup and let chunks_skipped++ in >>> raid10_sync_request() if there are some bad_blocks, and it will return >>> max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and >>> data is inconsistent but user think recovery is done, it is wrong. >>> >>> Fix it by set mirror's recovery_disabled and spare device shouln't be >>> added to here. >>> >>> Signed-off-by: Li Nan <linan122@huawei.com> >>> --- >>> drivers/md/raid10.c | 16 +++++++++++++++- >>> 1 file changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c >>> index e21502c03b45..70cc87c7ee57 100644 >>> --- a/drivers/md/raid10.c >>> +++ b/drivers/md/raid10.c >>> @@ -3303,6 +3303,7 @@ static sector_t raid10_sync_request(struct >>> mddev *mddev, sector_t sector_nr, >>> int chunks_skipped = 0; >>> sector_t chunk_mask = conf->geo.chunk_mask; >>> int page_idx = 0; >>> + int error_disk = -1; >>> /* >>> * Allow skipping a full rebuild for incremental assembly >>> @@ -3386,7 +3387,18 @@ static sector_t raid10_sync_request(struct >>> mddev *mddev, sector_t sector_nr, >>> return reshape_request(mddev, sector_nr, skipped); >>> if (chunks_skipped >= conf->geo.raid_disks) { >>> - /* if there has been nothing to do on any drive, >>> + pr_err("md/raid10:%s: %s fail\n", mdname(mddev), >>> + test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ? "resync" >>> : "recovery"); >> >> Line exceed 80 columns, and following. >>> + if (error_disk >= 0 && !test_bit(MD_RECOVERY_SYNC, >>> &mddev->recovery)) { >> >> Resync has the same problem, right? >> > > Yes. But I have no idea to fix it. md_error disk nor set > recovery_disabled is a good solution. So, just print error message now. > Do you have any ideas? I'll look into this, in the meadtime, I don't suggest to apply this patch because this is just temporary solution that only fix half of the problem. Thanks, Kuai
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index e21502c03b45..70cc87c7ee57 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -3303,6 +3303,7 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, int chunks_skipped = 0; sector_t chunk_mask = conf->geo.chunk_mask; int page_idx = 0; + int error_disk = -1; /* * Allow skipping a full rebuild for incremental assembly @@ -3386,7 +3387,18 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, return reshape_request(mddev, sector_nr, skipped); if (chunks_skipped >= conf->geo.raid_disks) { - /* if there has been nothing to do on any drive, + pr_err("md/raid10:%s: %s fail\n", mdname(mddev), + test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ? "resync" : "recovery"); + if (error_disk >= 0 && !test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) { + /* + * recovery fail, set mirrors.recovory_disabled, + * device shouldn't be added to there. + */ + conf->mirrors[error_disk].recovery_disabled = mddev->recovery_disabled; + return 0; + } + /* + * if there has been nothing to do on any drive, * then there is nothing to do at all.. */ *skipped = 1; @@ -3640,6 +3652,8 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, mdname(mddev)); mirror->recovery_disabled = mddev->recovery_disabled; + } else { + error_disk = i; } put_buf(r10_bio); if (rb2)