Re: Possible issue with software RAID 1 in case of disks with different speed

On Sun, Dec 7, 2025 at 8:41 AM Christian Focke-Kiss
<[email protected]> wrote:
>
> Hello,
>

>
> Now, as long as the sixth disk was still connected via USB 3.x, the
> rsync job and a kworker job were 'blocked' after some hours of rsync-
> ing, and the console displayed some 'sync' errors, and I had to press
> Ctrl+Alt+Del to reboot the system because login didn't work anymore.
>
> I flagged the USB 3.x disk 'write-mostly' and 'nofailfast' but this
> didn't resolve the issue.
>
> Only after I added two NVMe SSDs as boot disks and migrated the sixth
> SSD into the sixth slot, everything runs fine.
>
> Conclusion:
> I suspect software RAID 1 has issues if one disk of a three disk RAID 1
> set is significantly slower than the other two disks.
>
> Everything works fine for me now, but in case ...
>
> Kind regards, Christian

I have seen enterprise grade array/controllers (SAN) that "defeated"
multipathd (older kernels, dm-mapper, same layer used by mdraid).
The way the "enterprise" array defeated multipath was that the array
controller was programmed to return  a TUR (test unit ready) when it
was alive and "believed" the "disk" it was managing was ok via its
paths, even when the "disk" it was managing was not really working.
The issue with that is some of the lower layers(the SCSI layer used
to/may still use a TUR as a health  check) when a timeout occurs sends
a TUR and if it gets the TUR response back than it retries the IO, and
it can get stuck in this loop under the right conditions and not fail
IO even though IO is not fuctioning because the TUR always works.   I
have seen multipath layers not process IO and not timeout/fail io from
this issue. for minutes to hours (often it never reports a timeout in
the logs because the TUR keeps works).  I had a discussion with the
enterprise raid people suggesting that during a failover the failing
controller should stop responding to TURs first and then stop
processing the IO instead of only stopping TURs when the controller
was rebooted.   It is quite possible that a USB controllers could be
doing the exact same thing(short circuiting and sending the TUR
itself, ie not a TUR from the actual disk)  and defeating the
timeout/failure code  in MDRAID even though the disk itself is not
responding.