linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Bityutskiy, Artem" <artem.bityutskiy@intel.com>
To: "beanhuo@micron.com" <beanhuo@micron.com>,
	"richard@nod.at" <richard@nod.at>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: master node can not be recovered
Date: Wed, 4 Nov 2015 08:25:59 +0000	[thread overview]
Message-ID: <1446625558.20949.31.camel@intel.com> (raw)
In-Reply-To: <1446625250.20949.26.camel@gmail.com>


On Wed, 2015-11-04 at 10:20 +0200, Artem Bityutskiy wrote:
> 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?

And by the way, from my point of view, if someone wants to add MLC
support, just fixing this problem is a good practical step forward. I
see a lot of discussions about MLC support, and we even have some
arguments, and the whole thing looks complex. But this is a much
smaller isolated piece of work which would contribute to the MLC
support effort, and the implementer would learn UBIFS while
implementing this, and would be a lot more confident about making UBIFS
changes. I think I can sense this attitude: oh, UBIFS is complex, let's
try to do most in UBI, it seems simpler to deal with.

-- 
Best Regards,

Artem Bityutskiy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

  reply	other threads:[~2015-11-04  8:26 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
2015-11-04  8:25           ` Bityutskiy, Artem [this message]
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=1446625558.20949.31.camel@intel.com \
    --to=artem.bityutskiy@intel.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).