From: Artem Bityutskiy <dedekind1@gmail.com>
To: Anatolij Gustschin <agust@denx.de>
Cc: linux-mtd@lists.infradead.org, Detlev Zundel <dzu@denx.de>
Subject: Re: UBIFS partition on NOR flash not mountable after power cut test
Date: Fri, 03 Dec 2010 12:28:05 +0200 [thread overview]
Message-ID: <1291372085.2365.49.camel@localhost> (raw)
In-Reply-To: <20101203110719.3a9d14f2@wker>
On Fri, 2010-12-03 at 11:07 +0100, Anatolij Gustschin wrote:
> UBI: scrubbed PEB 149 (LEB 0:19), data moved to PEB 40
>
> My question is: should this PEB really be preserved? I think, no.
> It was prepared for erasure and would be entirely erased if no
> interruption would occur.
Well, in general, my thinking is, if only the EC header is corrupted, we
do not know why - may be this was just because of some bit-flips or
radiation, and UBI better preserves it, just in case. I mean, there is a
risk to destroy useful data otherwise.
Then the upper layer SW like UBIFS should know what it was erasing, and
should re-issue the erasure. This is also a requirement made by the
"unstable bits" problem Matthiew found on NAND, and challenged me with.
To put is simple: I think it is saver for UBI to preserve it. Upper
layers will erase it again if it is not needed.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-12-03 10:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 18:50 UBIFS partition on NOR flash not mountable after power cut test Anatolij Gustschin
2010-11-29 20:33 ` Mark Mason
2010-12-02 3:47 ` Artem Bityutskiy
2010-12-02 4:10 ` Mark Mason
2010-12-02 9:17 ` Detlev Zundel
2010-11-30 10:41 ` Norbert van Bolhuis
2010-11-30 15:35 ` Anatolij Gustschin
2010-12-01 9:38 ` Anatolij Gustschin
[not found] ` <AANLkTikEDQyNttTcKgHLwhR53sYSFbtVK-oy2S3END46@mail.gmail.com>
2010-12-01 9:47 ` Norbert van Bolhuis
2010-12-01 9:55 ` Anatolij Gustschin
[not found] ` <AANLkTikci0e2jaHCarA9HG86b_C-1UUcT_PMy-Q_mBrP@mail.gmail.com>
2010-12-01 13:06 ` Norbert van Bolhuis
2010-12-02 3:51 ` Artem Bityutskiy
2010-12-01 12:05 ` Anatolij Gustschin
2010-12-01 15:44 ` Anatolij Gustschin
2010-12-02 4:01 ` Artem Bityutskiy
2010-12-02 4:42 ` Artem Bityutskiy
2010-12-02 9:46 ` Matthieu CASTET
2010-12-02 12:18 ` Artem Bityutskiy
2010-12-02 9:57 ` Anatolij Gustschin
2010-12-02 12:18 ` Artem Bityutskiy
2010-12-02 13:23 ` Anatolij Gustschin
2010-12-02 13:35 ` Artem Bityutskiy
2010-12-02 13:50 ` Anatolij Gustschin
2010-12-02 13:57 ` Artem Bityutskiy
2010-12-02 14:18 ` Anatolij Gustschin
2010-12-03 10:07 ` Anatolij Gustschin
2010-12-03 10:23 ` Anatolij Gustschin
2010-12-03 10:28 ` Artem Bityutskiy [this message]
2010-12-03 10:41 ` Anatolij Gustschin
2010-12-03 10:49 ` Artem Bityutskiy
2010-12-03 11:15 ` Anatolij Gustschin
2010-12-02 3:46 ` 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=1291372085.2365.49.camel@localhost \
--to=dedekind1@gmail.com \
--cc=agust@denx.de \
--cc=dzu@denx.de \
--cc=linux-mtd@lists.infradead.org \
/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.