* [PATCH] md/raid5: complete unsupported discards successfully
[not found] <CAO96y0V6oncv54ihXnHfJMYiG_QAQ-NM8BOdqPDXKL8r8-kR9Q@mail.gmail.com>
@ 2026-10-26 6:21 ` Konstantin Nikiforov
2026-11-06 3:26 ` yu kuai
0 siblings, 1 reply; 2+ messages in thread
From: Konstantin Nikiforov @ 2026-10-26 6:21 UTC (permalink / raw)
To: linux-raid
Cc: linux-bcache, regressions, linux-kernel, stable, yukuai, song,
magiclinan, xiao, colyli, kent.overstreet
Since commit 90573092673c ("md/raid5: validate discard support at
request time") raid5 advertises max_hw_discard_sectors = UINT_MAX no
matter whether the member devices support discard or
devices_handle_discard_safely is set, and make_discard_request() fails
the discards it cannot handle with BLK_STS_NOTSUPP.
Before that commit such arrays did not advertise discard at all, so
upper layers never sent one. Now they do, and the failure is not
harmless:
- bcache forwards discards to its backing device whenever
bdev_max_discard_sectors() is non-zero, and backing_request_endio()
treats every non-zero bi_status as a media error. After io_error_limit
(64) of them bch_cached_dev_error() stops the cached device. On a
machine with root on LVM over bcache over a raid5 of three HDDs the
root filesystem disappeared a few minutes after every boot.
- btrfs enables discard=async by default on any device that advertises
discard, which is what generated the discards in the first place.
Discard is advisory: blkdev_issue_discard() already turns -EOPNOTSUPP
into success for its callers, and md_submit_discard_bio() silently skips
raid0/raid10 members without discard support. Do the same here and
complete the bio successfully when the array cannot pass it down safely,
so that callers submitting their own discard bios, like bcache, see the
same behaviour.
Fixes: 90573092673c ("md/raid5: validate discard support at request time")
Cc: stable@vger.kernel.org # 7.2
Closes: https://lore.kernel.org/all/CAO96y0V6oncv54ihXnHfJMYiG_QAQ-NM8BOdqPDXKL8r8-kR9Q@mail.gmail.com/
Signed-off-by: Konstantin Nikiforov <helllamer@gmail.com>
---
Kuai, this is the raid5-side change you were fine with in the report
thread. Reproducer: raid5 over three loop devices with a bcache backing
device on top, four blkdiscard calls on the bcache device. On 7.2.11
without the patch bcache's io_errors goes to 4 (bch_count_backing_io_errors
in dmesg); with the patch applied to 7.2.11 it stays at 0, and the
affected machine (root on LVM over bcache over raid5 of HDDs) boots and
runs with the patched module without any backing-device errors.
blkdiscard on the md device itself reports success either way because
blkdev_issue_discard() masks EOPNOTSUPP.
One correction to my report: the "discard_granularity is 0" observation
was a side effect of my own workaround (writing 0 to discard_max_bytes
makes the block layer report granularity 0); on a fresh array the
granularity is the stripe size as expected.
drivers/md/raid5.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index b91545ce090d..b462b18e47ff 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1144,7 +1144,16 @@ static bool raid5_discard_limits(struct mddev *mddev, struct bio *bi)
if (!conf->raid5_discard_unsupported)
return true;
- bi->bi_status = BLK_STS_NOTSUPP;
+ /*
+ * Discard is advisory. The array advertises discard regardless of
+ * member support, so an upper layer may legitimately send discards
+ * that cannot be forwarded safely. Complete them successfully
+ * instead of failing them: bcache counts every failed backing
+ * device bio as an I/O error and stops the device after
+ * io_error_limit of them, and btrfs enables discard=async on any
+ * device that advertises discard. This also matches what
+ * md_submit_discard_bio() does for members without discard support.
+ */
bio_endio(bi);
return false;
}
base-commit: 6b4b543fa18757297ac756a6fe6e64f506b7844a
--
2.56.0
^ permalink raw reply [flat|nested] 2+ messages in thread