Re: [REGRESSION][BISECTED] Spurious raid1 device failure triggered by qemu direct IO on 6.18+

[Keith Busch]

On Wed, Apr 15, 2026 at 02:18:59PM +0200, Tomás Trnka wrote:
> Since 6.18, booting a VM that is backed by a raid1 LVM LV makes that LV 
> immediately eject one of the devices. This is apparently because of a direct 
> IO read by QEMU failing. I have bisected the issue to the following commit and 
> confirmed that reverting that commit (plus dependencies 
> 9eab1d4e0d15b633adc170c458c51e8be3b1c553 and 
> b475272f03ca5d0c437c8f899ff229b21010ec83) on top of 6.19.11 fixes the issue.
> 
> commit 5ff3f74e145adc79b49668adb8de276446acf6be
> Author: Keith Busch <kbusch@xxxxxxxxxx>
> Date:   Wed Aug 27 07:12:54 2025 -0700
> 
>     block: simplify direct io validity check
>     
>     The block layer checks all the segments for validity later, so no need
>     for an early check. Just reduce it to a simple position and total length
>     check, and defer the more invasive segment checks to the block layer.
>     
>     Signed-off-by: Keith Busch <kbusch@xxxxxxxxxx>
>     Reviewed-by: Hannes Reinecke <hare@xxxxxxx>
>     Reviewed-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
>     Reviewed-by: Christoph Hellwig <hch@xxxxxx>
>     Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
> 
> The issue looks like this:
> 
> md/raid1:mdX: dm-17: rescheduling sector 0
> md/raid1:mdX: redirecting sector 0 to other mirror: dm-17
> (snipped 9 repeats of the preceding two lines)
> md/raid1:mdX: dm-17: Raid device exceeded read_error threshold [cur 21:max 20]
> md/raid1:mdX: dm-17: Failing raid device
> md/raid1:mdX: Disk failure on dm-17, disabling device.
> md/raid1:mdX: Operation continuing on 1 devices.
> 
> There's absolutely nothing wrong with the HW, the issue persists even when I 
> move the mirrors to a different pair of PVs (SAS HDD vs SATA SSD).

Thanks for the notice and the logs. Sounds likek something is getting
sent to the block layer that can't form a viable IO. The commit you
identified should have still error'ed though, just much earlier in the
call stack.

Anyway, I'll take a look if there's something I missed handling with the
stacking setup you're describing.