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
next prev parent 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