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

["John Stoffel" <john@stoffel.org>]

>>>>> "G" == "G W Kant <- Hunenet B.V." <g.w.kant@hunenet.nl>> writes:

> Hi Abd,
> On 7/15/26 7:27 AM, Abd-Alrhman Masalkhi wrote:
>>> With today's 18–24 TB HDDs and backup/archive workloads, where data may
>>> remain unchanged for years, latent media degradation seems increasingly
>>> relevant. A successful read from the alternate mirror may be one of the
>>> last opportunities to refresh such a sector before it becomes
>>> permanently unreadable.
>>> 
>> And Check/Repair is the right defense for cold archival data on large
>> drives.


> I have been looking into your suggestion that periodic check/repair is 
> the appropriate defense for cold archival data on large drives.

> Before I start reading the resync code, I would like to make sure I 
> understand what repair actually does.

> Suppose all mirrors read successfully and contain identical data. In 
> other words, there are no read errors and no mismatches.

> Does repair simply verify the data and move on, or does it also rewrite 
> each successfully read block to the corresponding LBA on every mirror?

> The distinction is important for what I have in mind.

So you have to also think of other situations.  You have a RAID1
array, and one block gets corrupted, but is still readable.  How do
you tell which block is the proper one?  You need checksums or parity
or more copies to check against for consistency.  

It's not a simple problem.   For long term archiving, I would try to
use something with RAID6 or more, and ideally have a filesystem which
also checksums data.  This is what ZFS does, and which bcachefs does
as well, but since they're both out of kernel, I don't use either with
my current home linux setup.  

But for long term storage, that could be the way to go.  but then you
need to periodically scrub your data, which means reading it all,
checking the checksums and re-writing and fixing corruption.  

> My concern is not recovery from an existing read error—that is already 
> handled by fix_read_error()—but rather the long-term aging of cold 
> magnetic recordings.

You really need three or more disks with multiple parity and checksums
for long term storage.  


> If a sector is still readable today but is approaching the point where 
> the drive's ECC will eventually no longer be able to reconstruct it, 
> then a successful rewrite would effectively establish a new "write time" 
> for that sector. If the drive can no longer reliably store the data at 
> that location, the rewrite would also give the firmware an opportunity 
> to remap the sector.

> So my question is essentially:

> Does repair perform such a rewrite of successfully read blocks, or does 
> it only rewrite blocks when a read error or mismatch has already been 
> detected?

> Regards,

> Dion