[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7072d96b-c2d4-4225-ad4f-1cba8f683985@mgml.me>
Date: Tue, 9 Sep 2025 02:29:08 +0900
From: Kenta Akagi <k@...l.me>
To: Yu Kuai <yukuai1@...weicloud.com>, Li Nan <linan666@...weicloud.com>,
Song Liu <song@...nel.org>, Mariusz Tkaczyk <mtkaczyk@...nel.org>,
Guoqing Jiang <jgq516@...il.com>
Cc: linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
"yukuai (C)" <yukuai3@...wei.com>, Kenta Akagi <k@...l.me>
Subject: Re: [PATCH v3 1/3] md/raid1,raid10: Do not set MD_BROKEN on failfast
io failure
On 2025/09/08 10:20, Yu Kuai wrote:
>
>
> 在 2025/09/02 0:48, Kenta Akagi 写道:
>> In the current raid1_end_write_request implementation,
>> - md_error is called only in the Failfast case.
>> - Afterwards, if the rdev is not Faulty (that is, not Failfast,
>> or Failfast but the last rdev — which originally was not expected
>> MD_BROKEN in RAID1), R1BIO_WriteError is set.
>> In the suggested implementation, it seems that a non-Failfast write
>> failure will immediately mark the rdev as Faulty, without retries.
>
> I still prefer a common helper to unify the code, not sure if I still
> missing something ...
>
> In general, if bio failed, for read/write/metadata/resync should be the
> same:
>
> 1) failfast is set, and not last rdev, md_error();
> 2) otherwise, we should always retry;
>
> And I do believe it's the best to unify this by a common helper.
Yes, I realized that my idea is bad. Your idea is best,
especially considering the error handling in super_written.
I'll implement a common helper.
By the way, I think md_error should only be serialized on RAID1 and 10
for now. Serializing unnecessary personalities is inefficient and can
lead to unfavorable results. What do you think?
Thanks,
Akagi
> Thanks,
> Kuai
>
>
Powered by blists - more mailing lists