Re: Block-level CRC checks

Kevin Grittner wrote:
>>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Paul Schlie <schlie(at)comcast(dot)net> writes:
>>> - yes, if you're willing to compute true CRC's as opposed to
>>> simpler checksums, which may be worth the price if in fact many/most
>>> data check failures are truly caused by single bit errors somewhere
>>> in the chain,
>>
>> FWIW, not one of the corrupted-data problems I've investigated has
>> ever looked like a single-bit error. So the theoretical basis for
>> using a CRC here seems pretty weak. I doubt we'd even consider
>> automatic repair attempts anyway.
>
> +1
>
> The only single-bit errors I've seen have been the result of a buggy
> driver for a particular model of network card. The problem went away
> with the next update of the driver. I've never encountered a
> single-bit error in a disk sector.

- although I personally don't see how a buggy driver could ever likely
generate single bit errors within the data stored/retrieved, as most
typically have no business mucking with data beyond breaking-it-up or
collating it into larger chunks typically on octet boundaries, unless
implementing a soft usart or something like that for some odd reason.

- however regardless, if some form of error detection ends up being
implemented, it might be nice to actually log corrupted blocks of data
along with their previously computed checksums for subsequent analysis
in an effort to ascertain if there's an opportunity to improve its
implementation based on this more concrete real-world information.