From: Roman Mamedov <rm@romanrm.net>
To: Zheng Qixing <zhengqixing@huaweicloud.com>
Cc: song@kernel.org, yukuai@fnnas.com, linux-raid@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, houtao1@huawei.com,
linan122@h-partners.com, zhengqixing@huawei.com
Subject: Re: [RFC PATCH 0/5] md/raid1: introduce a new sync action to repair badblocks
Date: Tue, 6 Jan 2026 18:50:02 +0500 [thread overview]
Message-ID: <20260106185002.2afbd215@nvm> (raw)
In-Reply-To: <d00be167-741a-4569-a51e-38b36325826e@huaweicloud.com>
On Tue, 6 Jan 2026 10:44:38 +0800
Zheng Qixing <zhengqixing@huaweicloud.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
next prev parent reply other threads:[~2026-01-06 13:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 7:09 [RFC PATCH 0/5] md/raid1: introduce a new sync action to repair badblocks Zheng Qixing
2025-12-31 7:09 ` [RFC PATCH 1/5] md: add helpers for requested sync action Zheng Qixing
2026-01-06 12:59 ` Li Nan
2026-01-08 3:31 ` Zheng Qixing
2025-12-31 7:09 ` [RFC PATCH 2/5] md: clear stale sync flags when frozen before sync starts Zheng Qixing
2026-01-06 13:07 ` Li Nan
2025-12-31 7:09 ` [RFC PATCH 3/5] md: simplify sync action print in status_resync Zheng Qixing
2026-01-06 13:24 ` Li Nan
2025-12-31 7:09 ` [RFC PATCH 4/5] md: introduce MAX_RAID_DISKS macro to replace magic number Zheng Qixing
2025-12-31 18:00 ` John Stoffel
2026-01-04 2:06 ` Zheng Qixing
2025-12-31 7:09 ` [RFC PATCH 5/5] md/raid1: introduce rectify action to repair badblocks Zheng Qixing
2026-01-06 13:43 ` Li Nan
2026-01-19 2:51 ` Zheng Qixing
2026-01-14 3:11 ` Li Nan
2026-01-19 3:06 ` Zheng Qixing
2025-12-31 11:11 ` [RFC PATCH 0/5] md/raid1: introduce a new sync " Roman Mamedov
2026-01-06 2:44 ` Zheng Qixing
2026-01-06 13:50 ` Roman Mamedov [this message]
2026-01-06 15:36 ` Pascal Hambourg
2026-01-08 1:32 ` Zheng Qixing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260106185002.2afbd215@nvm \
--to=rm@romanrm.net \
--cc=houtao1@huawei.com \
--cc=linan122@h-partners.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai@fnnas.com \
--cc=zhengqixing@huawei.com \
--cc=zhengqixing@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox