Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu CASTET <matthieu.castet@parrot.com>
To: Pekon Gupta <pekon@ti.com>
Cc: Kent Li <Kent.Li@radisys.com>, Stefan Roese <sr@denx.de>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	HOUR Frderic <frederic.hour@safran-engineering.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Brian Norris <computersforpeace@gmail.com>
Subject: Re: [RFC PATCH] UBIFS: remove check for all(0xff) for empty pages
Date: Tue, 11 Mar 2014 13:35:33 +0100	[thread overview]
Message-ID: <20140311133533.7ae34928@parrot.com> (raw)
In-Reply-To: <1394518992-26969-1-git-send-email-pekon@ti.com>

Le Tue, 11 Mar 2014 11:53:12 +0530,
Pekon Gupta <pekon@ti.com> a écrit :

> UBIFS throws following error if an blank page does not contain perfect all(0xff)
> data, during LEB scan, even though if number of bit-flips is within ecc.strength
> 	"UBIFS error (pid 1): ubifs_scan: corrupt empty space at LEB 417:53168"
> 
> But newer technology devices (like MLC NAND) are prone to read-disturb bit-flips
> and so having perfect all(0xff) data on empty-pages is practically not feasible
> on these newer technology devices (like MLC NAND).
> Also, such device spec suggest using stronger ECC schemes (like BCH16), and have
> large OOB size to guarantee longer field life.
> 
> So this check of perfect all(0xff) data can be safely removed from UBIFS, as
> UBI and MTD layers already these before passing the data to UBIFS:
>  if (number-of-bitflips < mtd->bitflip_threshold)
>         Driver's ECC scheme is strong enough to handle existing bit-flips in
>         future, so both MTD and UBI ignore such bit-flips.
>  if (number-of-bitflips >= mtd->bitflip_threshold)
>         MTD flags -EUCLEAN.
>         UBI schedules the block for scrubbing.
>  if (number-of-bitflips > nand_chip->ecc.strength)
>         MTD flags -EBADMSG.
>         UBI tries to extract data relevant data from block based on sanity of
>         its headers, and then schedule it for re-erase.

If the mtd layer check the number of bitflip on empty page why it
doesn't correct it and UBIFS see all 0xff ?

In the other hand if mtd layer is not able to check empty page this is
very dangerous. What happen if an empty page already have too much
bitflip ?
The data we write on this page will be corrupted.

In my opinion the change should be done on mtd/UBI layer not ubifs. 
The main problem today is that some driver don't read empty page with
ecc (because their ecc of empty page is not 0xff).
We can add metadata (in spare because ubifs want power of 2
write unit !) that can help to see it the page is empty or not.


Matthieu

  parent reply	other threads:[~2014-03-11 12:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11  6:23 [RFC PATCH] UBIFS: remove check for all(0xff) for empty pages Pekon Gupta
2014-03-11  7:42 ` Artem Bityutskiy
2014-03-11 11:41   ` Gupta, Pekon
2014-03-11 12:21   ` Matthieu CASTET
2014-03-11 13:06     ` Artem Bityutskiy
2014-03-11 12:35 ` Matthieu CASTET [this message]
2014-03-11 12:51   ` Kent Li
2014-03-21  7:57   ` Gupta, Pekon

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=20140311133533.7ae34928@parrot.com \
    --to=matthieu.castet@parrot.com \
    --cc=Kent.Li@radisys.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=frederic.hour@safran-engineering.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    --cc=sr@denx.de \
    /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