All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Dugas <dugaso@sonatest.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: Bitbake do_unpack checksum?
Date: Mon, 22 Sep 2014 15:37:37 -0400	[thread overview]
Message-ID: <54207A81.9070102@sonatest.com> (raw)
In-Reply-To: <CAJTo0Lbfg7nz7vYLOhT2VuxDCCeO0eBVtmer+ODFQTwfgncTrA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

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@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


[-- Attachment #2: Type: text/html, Size: 2988 bytes --]

  reply	other threads:[~2014-09-22 19:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-22 15:08 Bitbake do_unpack checksum? Olivier Dugas
2014-09-22 16:16 ` Burton, Ross
2014-09-22 16:18   ` Burton, Ross
2014-09-22 17:04     ` Olivier Dugas
2014-09-22 19:20       ` Burton, Ross
2014-09-22 19:37         ` Olivier Dugas [this message]
2014-09-22 22:20           ` Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54207A81.9070102@sonatest.com \
    --to=dugaso@sonatest.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.