Re: [PATCH v6 1/2] md: Don't set MD_BROKEN for RAID1 and RAID10 when using FailFast

On 2026/09/17 22:58, Martin Wilck wrote:

Hello Kenta, all,

On Fri, 2026-01-16 at 11:04 +0900, Kenta Akagi wrote:

quoted

On 2026/01/07 12:35, Xiao Ni wrote:

quoted

On Tue, Jan 6, 2026 at 8:30 PM Kenta Akagi [off-list ref] wrote:

quoted

Hi,
Thank you for reviewing.

On 2026/01/06 11:57, Li Nan wrote:

quoted

在 2026/1/5 22:40, Kenta Akagi 写道:

quoted

After commit 9631abdbf406 ("md: Set MD_BROKEN for RAID1 and
RAID10"),
if the error handler is called on the last rdev in RAID1 or
RAID10,
the MD_BROKEN flag will be set on that mddev.
When MD_BROKEN is set, write bios to the md will result in an
I/O error.

This causes a problem when using FailFast.
The current implementation of FailFast expects the array to
continue
functioning without issues even after calling md_error for
the last
rdev.  Furthermore, due to the nature of its functionality,
FailFast may
call md_error on all rdevs of the md. Even if retrying I/O on
an rdev
would succeed, it first calls md_error before retrying.

To fix this issue, this commit ensures that for RAID1 and
RAID10, if the
last In_sync rdev has the FailFast flag set and the mddev's
fail_last_dev
is off, the MD_BROKEN flag will not be set on that mddev.

This change impacts userspace. After this commit, If the rdev
has the
FailFast flag, the mddev never broken even if the failing bio
is not
FailFast. However, it's unlikely that any setup using
FailFast expects
the array to halt when md_error is called on the last rdev.

In the current RAID design, when an IO error occurs, RAID
ensures faulty
data is not read via the following actions:
1. Mark the badblocks (no FailFast flag); if this fails,
2. Mark the disk as Faulty.

If neither action is taken, and BROKEN is not set to prevent
continued RAID
use, errors on the last remaining disk will be ignored.
Subsequent reads
may return incorrect data. This seems like a more serious issue
in my opinion.

I agree that data inconsistency can certainly occur in this
scenario.

However, a RAID1 with only one remaining rdev can considered the
same as a plain
disk. From that perspective, I do not believe it is the mandatory
responsibility
of md raid to block subsequent writes nor prevent data
inconsistency in this situation.

The commit 9631abdbf406 ("md: Set MD_BROKEN for RAID1 and
RAID10") that introduced
BROKEN for RAID1/10 also does not seem to have done so for that
responsibility.

quoted

In scenarios with a large number of transient IO errors, is
FailFast not a
suitable configuration? As you mentioned: "retrying I/O on an
rdev would

It seems be right about that. Using FailFast with unstable
underlayer is not good.
However, as md raid, which is issuer of FailFast bios,
I believe it is incorrect to shutdown the array due to the
failure of a FailFast bio.

Hi all

I understand @Li Nan 's point now. The badblock can't be recorded
in
this situation and the last working device is not set to faulty. To
be
frank, I think consistency of data is more important. Users don't
think it's a single disk, they must think raid1 should guarantee
the
consistency. But the write request should return an error when
calling
raid1_error for the last working device, right? So there is no
consistency problem?

Hi all,

I understand that when md_error is issued for the last remaining
rdev, 
the array should be stopped except in the failfast case, also, 
it is no longer appropriate to treat an RAID1 array that has lost 
redundancy as "just a normal single drive" [1].

I will post an PATCH v7 based on v5.

I wonder what became of this v7 series. Have you given up on this?
If yes, what is the bottom line - simply not using failfast in setups
like the one you described?

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.

Thanks,
Akagi

Martin

-- 
Dr. Martin Wilck [off-list ref]
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg,
Germany
Geschäftsführer: Stefan Gaiser, Jochen Jaser, Abhinav Puri (HRB
36809,AG Nürnberg)