From: Kenta Akagi <k@mgml.me>
To: Song Liu <song@kernel.org>, Yu Kuai <yukuai3@huawei.com>,
Mariusz Tkaczyk <mtkaczyk@kernel.org>, Shaohua Li <shli@fb.com>,
Guoqing Jiang <jgq516@gmail.com>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
Kenta Akagi <k@mgml.me>
Subject: [PATCH v4 5/9] md/raid1,raid10: Set R{1,10}BIO_Uptodate when successful retry of a failed bio
Date: Mon, 15 Sep 2025 12:42:06 +0900 [thread overview]
Message-ID: <20250915034210.8533-6-k@mgml.me> (raw)
In-Reply-To: <20250915034210.8533-1-k@mgml.me>
In the current implementation, when a write bio fails, the retry flow
is as follows:
* In bi_end_io, e.g. raid1_end_write_request, R1BIO_WriteError is
set on the r1bio.
* The md thread calls handle_write_finished corresponding to this r1bio.
* Inside handle_write_finished, narrow_write_error is invoked.
* narrow_write_error rewrites the r1bio on a per-sector basis, marking
any failed sectors as badblocks. It returns true if all sectors succeed,
or if failed sectors are successfully recorded via rdev_set_badblock.
It returns false if rdev_set_badblock fails or if badblocks are disabled.
* handle_write_finished faults the rdev if it receives false from
narrow_write_error. Otherwise, it does nothing.
This can cause a problem where an r1bio that succeeded on retry is
incorrectly reported as failed to the higher layer, for example in the
following case:
* Only one In_sync rdev exists, and
* The write bio initially failed but all retries in
narrow_write_error succeed.
This commit ensures that if a write initially fails but all retries in
narrow_write_error succeed, R1BIO_Uptodate or R10BIO_Uptodate is set
and the higher layer receives a successful write status.
Signed-off-by: Kenta Akagi <k@mgml.me>
---
drivers/md/raid1.c | 32 ++++++++++++++++++++++++++------
drivers/md/raid10.c | 21 +++++++++++++++++++++
2 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 8fff9dacc6e0..806f5cb33a8e 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2517,6 +2517,21 @@ static void fix_read_error(struct r1conf *conf, struct r1bio *r1_bio)
}
}
+/**
+ * narrow_write_error() - Retry write and set badblock
+ * @r1_bio: the r1bio containing the write error
+ * @i: which device to retry
+ *
+ * Rewrites the bio, splitting it at the least common multiple of the logical
+ * block size and the badblock size. Blocks that fail to be written are marked
+ * as bad. If badblocks are disabled, no write is attempted and false is
+ * returned immediately.
+ *
+ * Return:
+ * * %true - all blocks were written or marked bad successfully
+ * * %false - bbl disabled or
+ * one or more blocks write failed and could not be marked bad
+ */
static bool narrow_write_error(struct r1bio *r1_bio, int i)
{
struct mddev *mddev = r1_bio->mddev;
@@ -2614,9 +2629,9 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
int m, idx;
bool fail = false;
- for (m = 0; m < conf->raid_disks * 2 ; m++)
+ for (m = 0; m < conf->raid_disks * 2 ; m++) {
+ struct md_rdev *rdev = conf->mirrors[m].rdev;
if (r1_bio->bios[m] == IO_MADE_GOOD) {
- struct md_rdev *rdev = conf->mirrors[m].rdev;
rdev_clear_badblocks(rdev,
r1_bio->sector,
r1_bio->sectors, 0);
@@ -2628,12 +2643,17 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
*/
fail = true;
if (!narrow_write_error(r1_bio, m))
- md_error(conf->mddev,
- conf->mirrors[m].rdev);
+ md_error(conf->mddev, rdev);
/* an I/O failed, we can't clear the bitmap */
- rdev_dec_pending(conf->mirrors[m].rdev,
- conf->mddev);
+ else if (test_bit(In_sync, &rdev->flags) &&
+ !test_bit(Faulty, &rdev->flags) &&
+ rdev_has_badblock(rdev,
+ r1_bio->sector,
+ r1_bio->sectors) == 0)
+ set_bit(R1BIO_Uptodate, &r1_bio->state);
+ rdev_dec_pending(rdev, conf->mddev);
}
+ }
if (fail) {
spin_lock_irq(&conf->device_lock);
list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index b73af94a88b0..21c2821453e1 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2809,6 +2809,21 @@ static void fix_read_error(struct r10conf *conf, struct mddev *mddev, struct r10
}
}
+/**
+ * narrow_write_error() - Retry write and set badblock
+ * @r10_bio: the r10bio containing the write error
+ * @i: which device to retry
+ *
+ * Rewrites the bio, splitting it at the least common multiple of the logical
+ * block size and the badblock size. Blocks that fail to be written are marked
+ * as bad. If badblocks are disabled, no write is attempted and false is
+ * returned immediately.
+ *
+ * Return:
+ * * %true - all blocks were written or marked bad successfully
+ * * %false - bbl disabled or
+ * one or more blocks write failed and could not be marked bad
+ */
static bool narrow_write_error(struct r10bio *r10_bio, int i)
{
struct bio *bio = r10_bio->master_bio;
@@ -2975,6 +2990,12 @@ static void handle_write_completed(struct r10conf *conf, struct r10bio *r10_bio)
fail = true;
if (!narrow_write_error(r10_bio, m))
md_error(conf->mddev, rdev);
+ else if (test_bit(In_sync, &rdev->flags) &&
+ !test_bit(Faulty, &rdev->flags) &&
+ rdev_has_badblock(rdev,
+ r10_bio->devs[m].addr,
+ r10_bio->sectors) == 0)
+ set_bit(R10BIO_Uptodate, &r10_bio->state);
rdev_dec_pending(rdev, conf->mddev);
}
bio = r10_bio->devs[m].repl_bio;
--
2.50.1
next prev parent reply other threads:[~2025-09-15 3:43 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 3:42 [PATCH v4 0/9] Don't set MD_BROKEN on failfast bio failure Kenta Akagi
2025-09-15 3:42 ` [PATCH v4 1/9] md/raid1,raid10: Set the LastDev flag when the configuration changes Kenta Akagi
2025-09-18 1:00 ` Yu Kuai
2025-09-18 14:02 ` Kenta Akagi
2025-09-21 7:54 ` Xiao Ni
2025-09-21 14:48 ` Kenta Akagi
2025-09-15 3:42 ` [PATCH v4 2/9] md: serialize md_error() Kenta Akagi
2025-09-18 1:04 ` Yu Kuai
2025-09-21 6:11 ` Kenta Akagi
2025-09-15 3:42 ` [PATCH v4 3/9] md: introduce md_bio_failure_error() Kenta Akagi
2025-09-18 1:09 ` Yu Kuai
2025-09-18 14:56 ` Kenta Akagi
2025-09-15 3:42 ` [PATCH v4 4/9] md/raid1,raid10: Don't set MD_BROKEN on failfast bio failure Kenta Akagi
2025-09-18 1:26 ` Yu Kuai
2025-09-18 15:22 ` Kenta Akagi
2025-09-19 1:36 ` Yu Kuai
2025-09-20 6:30 ` Kenta Akagi
2025-09-20 9:51 ` Yu Kuai
2025-09-23 15:54 ` Kenta Akagi
2025-09-15 3:42 ` Kenta Akagi [this message]
2025-09-17 9:24 ` [PATCH v4 5/9] md/raid1,raid10: Set R{1,10}BIO_Uptodate when successful retry of a failed bio Li Nan
2025-09-17 13:20 ` Kenta Akagi
2025-09-18 6:39 ` Li Nan
2025-09-18 15:36 ` Kenta Akagi
2025-09-19 1:37 ` Li Nan
2025-09-15 3:42 ` [PATCH v4 6/9] md/raid1,raid10: Fix missing retries Failfast write bios on no-bbl rdevs Kenta Akagi
2025-09-17 10:06 ` Li Nan
2025-09-17 13:33 ` Kenta Akagi
2025-09-18 6:58 ` Li Nan
2025-09-18 16:23 ` Kenta Akagi
2025-09-19 1:28 ` Li Nan
2025-09-15 3:42 ` [PATCH v4 7/9] md/raid10: fix failfast read error not rescheduled Kenta Akagi
2025-09-18 7:38 ` Li Nan
2025-09-18 16:12 ` Kenta Akagi
2025-09-19 1:20 ` Li Nan
2025-09-15 3:42 ` [PATCH v4 8/9] md/raid1,raid10: Add error message when setting MD_BROKEN Kenta Akagi
2025-09-15 3:42 ` [PATCH v4 9/9] md/raid1,raid10: Fix: Operation continuing on 0 devices Kenta Akagi
2025-09-15 7:19 ` Paul Menzel
2025-09-15 8:19 ` Kenta Akagi
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=20250915034210.8533-6-k@mgml.me \
--to=k@mgml.me \
--cc=jgq516@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=mtkaczyk@kernel.org \
--cc=shli@fb.com \
--cc=song@kernel.org \
--cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox