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: <20260106185002.2afbd215@nvm>
Date: Tue, 6 Jan 2026 18:50:02 +0500
From: Roman Mamedov <rm@...anrm.net>
To: Zheng Qixing <zhengqixing@...weicloud.com>
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 Tue, 6 Jan 2026 10:44:38 +0800
Zheng Qixing <zhengqixing@...weicloud.com> wrote:

> Are you referring to the case where we have logical 512B sectors but 
> physical 4K sectors?

At least that, yes. Such rewriting of bad blocks should happen at least at the
physical sector granularity.

But from my limited experience it feels like the badblock recovery algorithm
in hard drives, in addition to being opaque and proprietary, also highly
indeterministic and possibly buggy. In one case it would take REPEATEDLY
overwriting a full megabyte around a bad block to finally make the drive remap
it. (Maybe less than a megabyte would do, but overwriting only 4K - didn't).
Of course I understand such endeavors are outside of scope for mdraid, hence
it was just a side note.

-- 
With respect,
Roman