From: Artem Bityutskiy <dedekind1@gmail.com>
To: Steve B <steve@baconbits.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI/UBFS: ubi_eba_read_leb() reporting unmapped LEB
Date: Mon, 20 Oct 2014 18:47:42 +0300 [thread overview]
Message-ID: <1413820062.7906.376.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1410201624320.2556@ubuntu>
On Mon, 2014-10-20 at 16:25 +0100, Steve B wrote:
> Thank you very much for your suggestions Artem, gives me plenty to look
> into :)
May be this will be also a useful piece of data.
Back several years ago, we saw ext4 not recovering after power cuts on
eMMC.
We knew ext4 is extremely complex, so we decided to go and test if eMMC
does the right job. Namely, if I submit data, they sync, does eMMC make
sure the data are on the media?
Adrian (the other UBIFS author) implemented the eMMC power cut test. And
he found that you may write to block A, they sync, then write to block
B, and have power cut, and after reboot block A is corrupted. So
interrupted write to block B affected a different block A.
We reported to the eMMC vendor, and the vendor acknowledged the problem
and we got newer eMMC, which was devoid of the issue. And our ext4
issues went away, it became a lot better.
This is why I say may be stressing UBI could be a good idea. It may be
waste of time too, though, if the problem is in UBIFS, or if the test
won't reveal a problem in UBI because the test is not good enough. But
it may also hit the nail quickly.
Artem.
next prev parent reply other threads:[~2014-10-20 15:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 13:45 UBI/UBFS: ubi_eba_read_leb() reporting unmapped LEB Steve B
2014-10-20 8:54 ` Steve B
2014-10-20 13:35 ` Artem Bityutskiy
2014-10-20 13:48 ` Steve B
2014-10-20 14:05 ` Artem Bityutskiy
2014-10-20 14:51 ` Steve B
2014-10-20 15:19 ` Artem Bityutskiy
2014-10-20 15:25 ` Steve B
2014-10-20 15:47 ` Artem Bityutskiy [this message]
2014-10-20 16:33 ` Steve B
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=1413820062.7906.376.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=steve@baconbits.demon.co.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox