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 13:04:05 -0400	[thread overview]
Message-ID: <54205685.2060104@sonatest.com> (raw)
In-Reply-To: <CAJTo0LZgRQNZF1_gjOvrMfNCaaServst1FiU9tjrDE5CbHEBKQ@mail.gmail.com>

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

Hi Ross and thank you for having taken the time,
I agree about the fact that if the disk might suffer from random bit 
flips, I couldn't trust it. In fact, like proposed there 
(https://wiki.yoctoproject.org/wiki/Build_Performance), I optimised the 
build performance knowing that the file system image would be built 
faster at the costs implied, which are (among others) that I could not 
trust the image.

The only thing that gets on a disk that is totally healthy (because we 
need to keep away from bit flips) is the download folder with all the 
tarballs. Still, you know that bit flips can occur, granted that it's 
much less frequent. The problem here is that it's the first time maybe 3 
years that a bit flip occured. So it's not really a problem about disk 
about to fail, but more about random flips caused by say solar wind or 
something!

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.

Best regards,

*Olivier*

Le 2014-09-22 12:18, Burton, Ross a écrit :
> On 22 September 2014 17:16, Burton, Ross <ross.burton@intel.com> wrote:
>> No, it wouldn't be hard.
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571
> I hit sent a little early then.  5571 is a related issue, but if
> you're a disk which is suffering from random bit flips, then do you
> want to trust it to building a file system image that likely is
> corrupted?  By extension we should checksum every file we generate
> just in case they get corrupted too...
>
> Ross


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

  reply	other threads:[~2014-09-22 17:04 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 [this message]
2014-09-22 19:20       ` Burton, Ross
2014-09-22 19:37         ` Olivier Dugas
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=54205685.2060104@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.