Hi,
在 2025/05/19 19:19, Yu Kuai 写道:
The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
raid10 to pass down all the flags from the incoming bio. The problem is
when we pass down the REQ_RAHEAD flag - bios with this flag may fail
anytime and md-raid is not prepared to handle this failure.
Can dm-raid handle this falg? At least from md-raid array, for read
ahead IO, it doesn't make sense to kill that flag.
If we want to fall back to old behavior, can we kill that flag from
dm-raid?
Please ignore the last reply, I misunderstand your commit message, I
thought you said dm-raid, actually you said mdraid, and it's correct,
if read_bio faild raid1/10 will set badblocks which is not expected.
Then for reada head IO, I still think don't kill REQ_RAHEAD for
underlying disks is better, what do you think about skip handling IO
error for ead ahead IO?
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 657d481525be..b8b4fead31f3 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -380,7 +380,10 @@ static void raid1_end_read_request(struct bio *bio)
/* This was a fail-fast read so we definitely
* want to retry */
;
- else {
+ else if (bio->bi_opf & REQ_RAHEAD) {
+ /* don't handle readahead error, which can fail at
anytime. */
+ uptodate = 1;
+ } else {
/* If all other devices have failed, we want to return
* the error upwards rather than fail the last device.
* Here we redefine "uptodate" to mean "Don't want to
retry"
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index dce06bf65016..4d51aaf3b39b 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -399,6 +399,9 @@ static void raid10_end_read_request(struct bio *bio)
* wait for the 'master' bio.
*/
set_bit(R10BIO_Uptodate, &r10_bio->state);
+ } else if (bio->bi_opf & REQ_RAHEAD) {
+ /* don't handle readahead error, which can fail at
anytime. */
+ uptodate = 1;
} else {
/* If all other devices that store this block have
* failed, we want to return the error upwards rather
Thanks,
Kuai