linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Richard Weinberger" <richard@nod.at>,
	"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: master node can not be recovered
Date: Wed, 04 Nov 2015 10:20:50 +0200	[thread overview]
Message-ID: <1446625250.20949.26.camel@gmail.com> (raw)
In-Reply-To: <5639BBDE.5000604@nod.at>

On Wed, 2015-11-04 at 09:03 +0100, Richard Weinberger wrote:
> But if two or more pages are corrupted UBIFS will give up as this
> most not happen
> from UBIFS's point of view.

Right, and I hear that a lot of bug reports and frustration comes from
this. This worked with SLCs we were using when implementing UBIFS
(particularly, Samsung OneNAND was used, it was very high-quality
NAND). Nowadays, this needs to be changed.

UBIFS logic is this. If there is a corruption, then it must be in the
last used NAND page. Pages after this NAND page must contain empty
space.

A small complication, which is not important now, is that UBIFS may
operate with multiple NAND pages, this depends on what the driver tells
is the min. IO size.

No the logic behind this was that we always write data from the
beginning of the LEB, and continue to its end. In case of a power cut,
we can only get corruption in the last NAND page (or more strictly,
min. I/O unit) where we were writing to. The next NAND page and all the
NAND pages after it should be empty. The previous NAND page and all the
NAND pages before it should contain valid data (CRC OK).

Pretty simple. Worked well.

So what has to be changed in this logic? Obviously, the definition of
empty space should be changed, it seems, because obviously not every
driver wants/can ECC-protect the empty space.

What else?

  reply	other threads:[~2015-11-04  8:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 16:10 master node can not be recovered Bean Huo 霍斌斌 (beanhuo)
2015-11-02 16:46 ` Richard Weinberger
2015-11-03  9:12   ` Artem Bityutskiy
2015-11-04  7:43     ` Bean Huo 霍斌斌 (beanhuo)
2015-11-04  8:03       ` Richard Weinberger
2015-11-04  8:20         ` Artem Bityutskiy [this message]
2015-11-04  8:25           ` Bityutskiy, Artem
2015-11-04  8:40           ` Boris Brezillon
2015-11-04  8:57             ` Artem Bityutskiy
2015-12-04  7:51     ` Bean Huo 霍斌斌 (beanhuo)
2015-11-03  8:32 ` 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=1446625250.20949.26.camel@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=beanhuo@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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;
as well as URLs for NNTP newsgroup(s).