public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: "Nori, Sekhar" <nsekhar@ti.com>,
	"Huang Shijie" <b32955@freescale.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"Gupta, Pekon" <pekon@ti.com>, "Quadros, Roger" <rogerq@ti.com>,
	"Lothar Waßmann" <LW@karo-electronics.de>
Subject: Re: [PATCH] mtd: nand: omap: save Bad-Block-Table (BBT) on device
Date: Thu, 24 Jul 2014 12:11:56 -0700	[thread overview]
Message-ID: <20140724191156.GG3711@ld-irv-0074> (raw)
In-Reply-To: <20140724134018.GA711@arch.cereza>

Hi Ezequiel,

On Thu, Jul 24, 2014 at 10:40:18AM -0300, Ezequiel Garcia wrote:
> On 23 Jul 06:54 PM, Brian Norris wrote:
> > The only real backwards-compatibility concern you'd have for
> > unconditionally enabling on-flash BBT (like in this patch) is if you had
> > previous file system data in the last 4 blocks; nand_bbt will just
> > clobber it, breaking your file system. For this reason, using DT is
> > probably a good idea -- you're opting in, rather than being forced in by
> > a kernel upgrade.
> 
> FWIW, having the kernel wipe your precious data, is even worse than having
> him fail; which means this represents a much more serious drawback.
> This is why any modification to a NAND driver that involves a different
> 'view' of the flash, should be considered with a lot of care!

Yes, that's pretty serious. Perhaps there could be some more attention
paid to this issue (throwing out some half-baked ideas: tag partitions
as exclusive 'BBT' partitions, to ensure data / BBT separation; or
prevent nand_bbt from reserving non-empty blocks for BBT). But for now,
this issue can be best dealt with by using the supported DT option to
explicitly opt in.

> > Beyond the backwards-compatibility concern, you still have other
> > concerns about on-flash BBT's robustness. Limiting yourself to a region
> > of 4 blocks is one potential issue. There are others (e.g., lack of CRC
> > protection), but none that have been real show-stoppers. I have a few
> > generations of products running it here.
> 
> Hm.. Can you guys mention what's the benefit of using a BBT, against keeping
> the bad block mark in the OOB region? (Other than the fact that some ECC
> strength may not leave any available OOB).

The primary reason would be that NAND datasheets specify it these days
:) But a better argument: nobody guarantees that you can write a 
bad block marker to a worn out block; you may just get program failures.
This has been acknowledged by several developers over the last several
years, some of whom I think were quoting their recollection from talking
w/ manufacturers (does that make this 3rd-hand info?). Most recently,
Lothar brought this up [1].

Additionally, you get a boot-time performance improvement if you only
have to read a few pages, instead of a page or two from every block on
the flash.

Brian

[1] http://lists.infradead.org/pipermail/linux-mtd/2014-July/054767.html

  reply	other threads:[~2014-07-24 19:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 11:54 [PATCH] mtd: nand: omap: save Bad-Block-Table (BBT) on device Pekon Gupta
2014-07-23 12:05 ` Ezequiel Garcia
2014-07-23 16:26   ` Gupta, Pekon
2014-07-23 20:27     ` ezequiel
2014-07-24  1:54       ` Brian Norris
2014-07-24 13:40         ` Ezequiel Garcia
2014-07-24 19:11           ` Brian Norris [this message]
2014-07-24 17:56         ` 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=20140724191156.GG3711@ld-irv-0074 \
    --to=computersforpeace@gmail.com \
    --cc=LW@karo-electronics.de \
    --cc=b32955@freescale.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nsekhar@ti.com \
    --cc=pekon@ti.com \
    --cc=rogerq@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox