linux-kernel - Re: [RFC PATCH 0/5] md/raid1: introduce a new sync action to repair badblocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <be20c929-4a81-49fe-9c0d-67f2e116732a@plouf.fr.eu.org>
Date: Tue, 6 Jan 2026 16:36:52 +0100
From: Pascal Hambourg <pascal@...uf.fr.eu.org>
To: Zheng Qixing <zhengqixing@...weicloud.com>, Roman Mamedov <rm@...anrm.net>
Cc: song@...nel.org, yukuai@...as.com, linux-raid@...r.kernel.org,
 linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
 houtao1@...wei.com, linan122@...artners.com, zhengqixing@...wei.com
Subject: Re: [RFC PATCH 0/5] md/raid1: introduce a new sync action to repair
 badblocks

On 06/01/2026 at 03:44, Zheng Qixing wrote:
> 在 2025/12/31 19:11, Roman Mamedov 写道:
>> On Wed, 31 Dec 2025 15:09:47 +0800
>>
>> Could you also check here that it reads back successfully, and only 
>> then clear?
>>
>> Otherwise there are cases when the block won't read even after 
>> rewriting it.

I confirm. The rewrite is reported successful but SMART reallocation 
attributes did not change and a further read still fails.

> I'm a bit worried that reading the data again before clearing the bad 
> blocks might affect the performance of the bad block repair process.

Isn't it more worrying to clear bad blocks while they may still be bad ?
Bad blocks should be rare anyway, so performance impact should be low.

>> Side note, on some hardware it might be necessary to rewrite a larger area
>> around the problematic block, to finally trigger a remap. Not 512B, but at
>> least the native sector size, which is often 4K.
> 
> Are you referring to the case where we have logical 512B sectors but 
> physical 4K sectors?

Yes. Writing a single logical sector implies a read-modify-write of the 
whole underlying physical sector and will not complete if the read fails.

> Can a physical 4K block have partial recovery (e.g., one 512B sector 
> succeeds while the other 7 fail)?

Not in my experience. There seems to be a single ECC for the whole 
physical sector.