From: Richard Weinberger <richard@nod.at>
To: Tim Harvey <tharvey@gateworks.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-mtd@lists.infradead.org
Subject: Re: UBIFS corruption after power cut - possibly unstable bits issue?
Date: Mon, 26 Oct 2015 22:41:31 +0100 [thread overview]
Message-ID: <562E9E0B.5030204@nod.at> (raw)
In-Reply-To: <CAJ+vNU1J+MvyWgY1FPv4G7TxQLDtPJWdWw=DP5+1h2HcTi-SxQ@mail.gmail.com>
Tim,
Am 26.10.2015 um 21:31 schrieb Tim Harvey:
> What would be causing the bit-flips on the erased pages? Could it have
> something to do with the larger flash part having a much longer erase
> time?
According to NAND manufactures can happen also on empty space.
At the time when UBIFS was designed this was not known nor was it observed.
These days it seems to happen on some large/cheap NANDs.
> There shouldn't be anything writing to ubifs so I'm not clear what
> caused this to occur. Note that even if I remove the /etc/fstab that
> causes root to be re-mounted read/write I always see 'UBIFS (ubi0:0):
> recovery needed' and I'm not understanding what causes that but it
> makes me think that NAND is getting touched each and every boot by the
> recovery process.
>
>> In March there was an attempt to fix that in software.
>> But no mainline ready solution was presented so far:
>> http://lists.infradead.org/pipermail/linux-mtd/2014-March/052521.html
>>
>> It is not clear whether to implement this directly in gpmi-nand or MTD core.
>> Currently UBIFS assumes that empty spaces must contain only 0xff octets.
>> A naive approach would be removing that check from UBIFS, bit this can have
>> disastrous consequences as UBIFS's recovery algorithm relies on that.
>
> I think I ran across that approach right before the thread you pointed
> me to: http://thread.gmane.org/gmane.linux.drivers.mtd/52208
:-)
> the second case is not permanent corruption - when the system is
> power-cycled it comes up fine the next time.
Yeah, but have you checked how the temporary corruption looks like?
Thanks,
//richard
next prev parent reply other threads:[~2015-10-26 21:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 19:37 UBIFS corruption after power cut - possibly unstable bits issue? Tim Harvey
2015-10-26 20:01 ` Richard Weinberger
2015-10-26 20:31 ` Tim Harvey
2015-10-26 21:41 ` Richard Weinberger [this message]
2015-10-27 19:01 ` Tim Harvey
2015-10-27 19:52 ` Richard Weinberger
2015-11-02 20:27 ` Tim Harvey
2015-11-02 20:31 ` Tim Harvey
2015-11-02 21:31 ` Richard Weinberger
2015-11-02 22:11 ` Brian Norris
2015-11-03 13:38 ` Boris Brezillon
2015-11-16 15:01 ` Tim Harvey
2015-11-30 21:58 ` Tim Harvey
2015-12-01 9:12 ` Boris Brezillon
2015-11-03 9:10 ` Artem Bityutskiy
2015-11-03 10:06 ` Michal Suchanek
2015-11-03 10:18 ` Ricard Wanderlof
2015-11-03 10:43 ` Artem Bityutskiy
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=562E9E0B.5030204@nod.at \
--to=richard@nod.at \
--cc=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=tharvey@gateworks.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.