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: <0f2e2b2e-2721-492e-a1a6-99e1814c52fc@huaweicloud.com>
Date: Thu, 8 Jan 2026 09:32:31 +0800
From: Zheng Qixing <zhengqixing@...weicloud.com>
To: Pascal Hambourg <pascal@...uf.fr.eu.org>, 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


在 2026/1/6 23:36, Pascal Hambourg 写道:
> 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.

That makes sense. I will change it in the next version.

>
>> 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.

I will try to test with disks that have lbs=512 and pbs=4096.

If 512B IOs can be successfully issued, then the bad block repair logic 
does need to

consider the minimum repair length and alignment logic.


Thanks,

Qixing