From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from www5210.sakura.ne.jp (www5210.sakura.ne.jp [133.167.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D255131D39D for ; Tue, 9 Sep 2025 17:07:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=133.167.8.150 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757437661; cv=none; b=PZNA/TEyNP8m2wzfMD8IuPXSjDrfEc/k1WvYKqmmF02GXVk7uILghgd66+pOyeky4TTS5xffOhgcdp04hIwqe7ruKUts9i8y2OhAE74MJzdA83XwpBzV/GilyqTsNefoyWjgNFgJ0xBHiZEcRU6SFZNQgD+M3nYw0TZey0PAU98= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757437661; c=relaxed/simple; bh=jFtg9uvtWBlgiSq5qvFKzkSfdyQ+8wkH/QQBmofULvo=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=dJnjA/SDTFxQup0ikPWhSdJbO4jQ2ggbWqhOweNSTInzajvSuKO84kaLUQ04AvkTFu2cValbgpC3ec5Atm8fAoo0Zc17SIFvgDPssffYJWvRcNTSzff9T1TJEQ5AU4wwV/HOOm7omBZhHoL1yHQzK3lUfMWJXMH8qa0hSnzV768= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mgml.me; spf=pass smtp.mailfrom=mgml.me; dkim=pass (2048-bit key) header.d=mgml.me header.i=@mgml.me header.b=oyh1kGKe; arc=none smtp.client-ip=133.167.8.150 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mgml.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mgml.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mgml.me header.i=@mgml.me header.b="oyh1kGKe" Received: from NEET (p4487057-ipxg00s01tokaisakaetozai.aichi.ocn.ne.jp [114.153.80.57]) (authenticated bits=0) by www5210.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 589H7asc079535 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Sep 2025 02:07:36 +0900 (JST) (envelope-from k@mgml.me) DKIM-Signature: a=rsa-sha256; bh=C53fLZHIuuoTre7z9U9FNaSy3t4lJL6yHv3NiirB8u0=; c=relaxed/relaxed; d=mgml.me; h=Message-ID:Date:Subject:To:From; s=rs20250315; t=1757437656; v=1; b=oyh1kGKeUEdDlyAiFnk79pZYHyNGruQGkHO+wlUFEfyrod9F5Xso6KBCcqcs+Alj lI87WgoWAKaybwcZh+nMycSqF6zHEsEO4IjjEJzjch05iLuc6zJqxUbFi8NJXriw ZpS8LPjQoE2yR3bmZyR3qJSQSFJSwhtihbCzha8M3CwzO6w1UGhBnZ+jae3eim9H sKjxbG2/feQEgMgnoDfHs41aTnSFfvxBSyzUBiHzjkRtHDtR0F0fRiVaIVUXzIsO RkG7RJVcQNQ5uZFaiZ1PZOOeLmkofxNVASkOy1Beoz7e2F+nPJj4lE2VZgPyFnDE 3u1CI+qEe2l06fgkSHpNDg== Message-ID: <2a949451-23d0-44ef-94fb-46b40c98957b@mgml.me> Date: Wed, 10 Sep 2025 02:07:36 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, "yukuai (C)" , Kenta Akagi Subject: Re: [PATCH v3 1/3] md/raid1,raid10: Do not set MD_BROKEN on failfast io failure To: Yu Kuai , Li Nan , Song Liu , Mariusz Tkaczyk , Guoqing Jiang References: <20250828163216.4225-1-k@mgml.me> <20250828163216.4225-2-k@mgml.me> <6b3119f1-486e-4361-b04d-5e3c67a52a91@mgml.me> <3ea67e48-ce8a-9d70-a128-edf5eddf15f0@huaweicloud.com> <29e337bc-9eee-4794-ae1e-184ef91b9d24@mgml.me> <6edb5e2c-3f36-dc2c-3b41-9bf0e8ebb263@huaweicloud.com> <7e268dff-4f29-4155-8644-45be74d4c465@mgml.me> <48902d38-c2a1-b74d-d5fb-3d1cdc0b05dc@huaweicloud.com> <34ebcc5b-db67-49e0-a304-4882fa82e830@mgml.me> <7072d96b-c2d4-4225-ad4f-1cba8f683985@mgml.me> <62365ca9-3cdb-c213-b0d4-5480ad734dd6@huaweicloud.com> Content-Language: en-US From: Kenta Akagi In-Reply-To: <62365ca9-3cdb-c213-b0d4-5480ad734dd6@huaweicloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2025/09/09 10:02, Yu Kuai wrote: > Hi, > > 在 2025/09/09 1:29, Kenta Akagi 写道: >> 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? > > Just make code cleaner and I don't have preference here, md_error is > super cold path I think. Thank you for your advice. Understood. Thanks, Akagi > Thanks, > Kuai > >> >> Thanks, >> Akagi >> >>> Thanks, >>> Kuai >>> >>> >> >> . >> > >