Re: Subject: RFC: Read repair for md RAID1 after mirror read failures

On 7/15/26 9:27 AM, Yu Kuai wrote:
>> Thank you. fix_read_error() was exactly the piece I was looking for. I
>> had missed that md already performs read repair when another healthy
>> mirror is available.
>>
>> My situation was indeed different because the array had already lost one
>> member, so the successful read originated from Btrfs redundancy across
>> another md RAID1 rather than from the surviving md mirror.
>>
>> One question remains, though. check/repair periodically reads all
>> sectors, but as far as I understand it, successfully read sectors are
>> not rewritten. From a media aging perspective this is a different
>> problem than recovering from a read error. Have there ever been
>> discussions about a true media refresh pass that rewrites successfully
>> read sectors to refresh long-lived magnetic recordings?
> Perhaps this is what you looking for:
> 
> [RFC v2 0/5] md/raid1: introduce a new sync action to repair badblocks -
> Zheng Qixing
> <https://lore.kernel.org/all/20260203061259.609206-1- 
> [email protected]/>
> 
> However, AFAIK, Qixing no longer work in this area and there will not be
> new version.
> 
>> Best regards,
>> Dion Kant
> -- Thanks, Kuai

Hi Kuai,

Thank you, this is certainly closely related.

As I understand the proposed 'rectify' action, it operates on ranges
that are already present in an md member's bad-block table. It reads the
data from a healthy mirror, writes it to the corresponding LBA on the 
affected member, and clears the bad-block entry when the write succeeds.

That would be very useful, but I think it addresses a slightly different
problem from the media-refresh operation I had in mind.

The latter would proactively read and rewrite all allocated—or perhaps
all addressable—blocks, including blocks that are still read 
successfully and have never been entered in the bad-block table. The 
purpose would be to refresh cold magnetic recordings before they reach 
the point at which the drive reports the first UNC.

So I see three separate mechanisms:

1. read repair after a failed normal read (`fix_read_error()`);
2. repair of already recorded bad blocks (`rectify`);
3. proactive read-and-rewrite of still-readable cold data.

The proposed patch appears to implement the second mechanism, whereas my
remaining question concerns the third.

Nevertheless, `rectify` is highly relevant, and it is unfortunate that
the series may no longer be developed. I will study the patch set and 
its discussion.

Regards,
Dion Kant