[gentoo-user] Re: OT: Fighting bit rot

[Grant Edwards]

On 2013-01-08, Pandu Poluan <pandu@××××××.info> wrote:
> On Jan 8, 2013 11:20 PM, "Florian Philipp" <lists@×××××××××××.net> wrote:
>>
>
> -- snip --
>
>>
>> Hmm, good idea, albeit similar to the `md5sum -c`. Either tool leaves
>> you with the problem of distinguishing between legitimate changes (i.e.
>> a user wrote to the file) and decay.
>>
>> When you have completely static content, md5sum, rsync and friends are
>> sufficient. But if you have content that changes from time to time, the
>> number of false-positives would be too high. In this case, I think you
>> could easily distinguish by comparing both file content and time stamps.
>>
>> Now, that of course introduces the problem that decay could occur in the
>> same time frame as a legitimate change, thus masking the decay. To
>> reduce this risk, you have to reduce the checking interval.
>>
>> Regards,
>> Florian Philipp
>
> IMO, we're all barking up the wrong tree here...
>
> Before a file's content can change without user involvement, bit rot must
> first get through the checksum (CRC?) of the hard disk itself. There will
> be no 'gradual degradation of data', just 'catastrophic data loss'.

When a hard drive starts to fail, you don't unknowingly get back
"rotten" data with some bits flipped.  You get either a "seek error"
or "read error", and no data at all.  IIRC, the same is true for
attempts to read a failing CD.

However, if you've got failing RAM that doesn't have hardware ECC,
that often appears as corrupted data in files.  If a bit gets
erroneously flippped in a RAM page that's being used to cache file
data, and that page is marked as dirty, then the erroneous bits will
get written back to disk just like the rest of them.

-- 
Grant Edwards               grant.b.edwards        Yow! ... he dominates the
                                  at               DECADENT SUBWAY SCENE.
                              gmail.com