[bitbake-devel] Bitbake do_unpack checksum?

[Olivier Dugas]

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 :
> On 22 September 2014 18:04, Olivier Dugas <dugaso at sonatest.com> wrote:
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20140922/cfc7b9fe/attachment-0002.html>