[bitbake-devel] Bitbake do_unpack checksum?

[Burton, Ross]

On 22 September 2014 20:37, Olivier Dugas <dugaso at sonatest.com> wrote:
> I know that no journal and high write delay could corrupt my disk. In this
> event I would reformat and rebuild the image, no big deal. What seem to me
> like a big deal though is to have a healthy hard drive that will once every
> 2 year flip a bit randomly on one of my downloaded tarball, and not having
> bitbake verify the checksum just in case.
>
> When I say it this way, I realize having bitbake doing checksum for every
> already downloaded tarball in the system could indeed add significant
> overhead, like said by Richard Purdie, even if I thought that a checksum was
> a fast operation... So I'm stuck. What would be the best solution then? I
> can't see any other simple solution then the one you proposed in #5571.

I think that if you're worrying about a bit flipping once in two years
then there are far more important places it could flip than the source
tarball archives.  tarballs/zip files etc have CRCs internally so a
flipped bit will be detected.  A bit flipping inside a compiled object
before it reaches a CRC'd package won't be detected until it crashes
or executes incorrectly.

As far as I'm aware this is mostly a hypothetical problem: hard drives
employ CRC to detect errors when reading sectors and will remap as bad
sectors appears.  Wikipedia says "10 non-recoverable read errors in
every 10^16 bits" and they'll be reported to the operating system as a
bad sector error and not silent corruption.  I'm happy to live with
that error rate.

Ross