From: Artem Bityutskiy <dedekind1@gmail.com>
To: Matteo Mattei <matteo.mattei@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode
Date: Tue, 20 Mar 2012 12:39:43 +0200 [thread overview]
Message-ID: <1332239983.11468.14.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CAHea38St440q-T+FawSic=brdv-dHb7H7yXh0Unq028Op75zuQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> Hi guys,
>
> I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
>
> I already posted some requests to TI forum but I have no answers up to now:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
Well, this error was reported several times. AFAIR, there are 2 possible
causes for this.
1. Your driver does not protect the empty space. Normally the driver
corrects bit-flips using ECC, but some systems do not do this for empty
space, i.e., for the flash regions which have been erased but have never
been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
it reports about corrupt empty space.
You can fix this by fixing the driver, at least this is what people seem
to do. If this is impossible to fix, you can teach UBIFS to tolerate
bit-flips in the empty space.
2. More difficult issue which no one still dares to start fixing is the
unstable bits issue. I do not have time to work on this, so I offer
everyone assistance, but no on so far started working on this, AFAIK.
Here is the description of the issue:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
HTH.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-03-20 10:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-16 16:14 UBI/UBIFS issue: corrupt empty space => switched to read-only mode Matteo Mattei
2012-03-19 9:28 ` Matteo Mattei
2012-03-20 10:40 ` Artem Bityutskiy
2012-03-20 10:39 ` Artem Bityutskiy [this message]
2012-03-29 15:48 ` Matteo Mattei
2012-03-29 16:28 ` Matthieu CASTET
2012-04-13 15:20 ` Artem Bityutskiy
2012-04-14 12:11 ` Ivan Djelic
2012-04-14 12:32 ` Artem Bityutskiy
2012-04-17 8:48 ` Ivan Djelic
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=1332239983.11468.14.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=matteo.mattei@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox