my bad, you're right. I would need to recompute the checksum at every do_unpack().
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.

What do you think?

Olivier

Le 2014-09-22 15:20, Burton, Ross a écrit :

I personnally would be satisfied by the point made by Richard Purdie in bug 5571 (comment 2), that is putting the checksum into the .done file. I believe this would indeed avoid errors like the one we got here. Was it implemented? If somebody did this, do you know the commit id, so I can try to cherry pick it.

Comment 2 is designed to solve a different problem and won't catch the tarball on disk getting corrupted because it will simply be comparing a cached checksum in the .done file with the stated checksum in the recipe. I'm not sure what points in the Builld Performance page mean you couldn't trust the resulting image. There are some tweaks that mean data loss in the event of power failure (ie no journal, high write delay) but in this situation the corrupted disk can be reformatted as it only contains built objects and can be entirely regenerated. Ross