On 2026/09/23 17:29, Martin Wilck wrote:
Hi Kenta,
On Wed, 2026-09-23 at 04:08 +0000, Kenta Akagi wrote:
quoted
Hi Martin,
I have not given up on it, but I have not managed to post v7 yet.
I still think failfast should be usable even in setups like that.
It has been a while, but I intend to resume work on it.
My thinking is that, in the fastfail case, code to prevent total
failure could be placed in the end-IO code code path, e.g. by
attempting a retry directly from the md layer when the last rdev fails,
instead of setting failing the device. But I haven't thought it
through.
Hi Martin,
I may be misunderstanding your suggestion, but Neil's original failfast
implementation already retries a failed failfast I/O to the last rdev.
But a later change introduced a regression, which I intend to fix.
So the sequence should be:
1. The failfast bios to all mirrored rdevs fail.
2. The first rdev is marked faulty because its bio failed.
3. The other rdev is now the last, so it is not marked faulty.
4. Since the last rdev remains usable, its bio error handler
retries the I/O without failfast.
Thanks,
Akagi