linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Angus CLARK <angus.clark@st.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>, Barry Song <21cnbao@gmail.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Gabor Juhos <juhosg@openwrt.org>,
	linux-mtd@lists.infradead.org,
	Jonas Gorski <jonas.gorski@gmail.com>,
	Jamie Iles <jamie@jamieiles.com>,
	Ivan Djelic <ivan.djelic@parrot.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	David Woodhouse <David.Woodhouse@intel.com>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Kevin Cernekee <cernekee@gmail.com>,
	Kulikov Vasiliy <segooon@gmail.com>,
	Jim Quinlan <jim2101024@gmail.com>,
	Andres Salomon <dilinger@queued.net>,
	Axel Lin <axel.lin@gmail.com>, Anatolij Gustschin <agust@denx.de>,
	Mike Frysinger <vapier@gentoo.org>, Arnd Bergmann <arnd@arndb.de>,
	Lei Wen <leiwen@marvell.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Artem Bityutskiy <artem.bityutskiy@intel.com>,
	Florian Fainelli <florian@openwrt.org>,
	dedekind1@gmail.com, Peter Wippich <pewi@gw-instruments.de>,
	Matthieu CASTET <matthieu.castet@parrot.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Shmulik Ladkani <shmulik.ladkani@gmail.com>,
	Wolfram Sang <w.sang@pengutronix.de>,
	Chuanxiao Dong <chuanxiao.dong@intel.com>,
	Joe Perches <joe@perches.com>,
	Guillaume LECERF <glecerf@gmail.com>,
	Roman Tereshonkov <roman.tereshonkov@nokia.com>
Subject: Re: [PATCH v3 0/6] NAND BBM + BBT updates
Date: Thu, 19 Jan 2012 09:30:45 +0000	[thread overview]
Message-ID: <4F17E2C5.2000301@st.com> (raw)
In-Reply-To: <CAN8TOE9W2txK+tcnuFBKB3ZTp99Fx385=8zxq9N5cbthVJCwoA@mail.gmail.com>

On 01/18/2012 10:04 PM, Brian Norris wrote:
> On Tue, Jan 17, 2012 at 2:22 AM, Angus CLARK <angus.clark@st.com> wrote:
>> (Indeed, this issue was raised recently in a meeting with one of the major NAND
>> manufacturers, and the design enginner was horrified at the thought of relying
>> on the OOB for tracking worn blocks.)
> 
> That's interesting. I never had this impression, but perhaps the topic
> just never came up.
> 

Since it was first brought to our attention, we have sought clarification from a
number of sources.  The general consensus seems to be that if a block has gone
bad, then one cannot rely on any further operations succeeding, including
writing BB markers to the OOB area.  However, the extent to which this is a
problem in practice is less clear.  Many of us have been using OOB BB markers
for years without any issue, although perhaps we just haven't noticed!

> Anyway, the important question is: how does this impact the current
> solution I am developing? IMO, this seems primarily a matter of
> perspective, which would drive future development but does not
> fundamentally alter my proposed patch(es). 

Yes, I fully agree.  The patches add functionality that many of us would find
useful and should be regarded as a step in the right direction.

> Another note regarding the primary source: if the BBT is sufficiently
> corrupted (according to ECC), we fall back to the OOB markers. That
> doesn't make the flash-based BBT the 100% primary source, but I think
> it makes sense. This feature was pulled into the 3.2 release, BTW.

If the BBT becomes corrupted, then the best we can do is rely on OOB markers,
and your patch at least gives us a chance to recover information about blocks
that have gone bad through use.  However, it does concern me that the BBTs can
become corrupted in the first place.  Some systems have no other choice but to
rely on BBTs (e.g. no space or access to OOB).  For SLC NAND at least, the
pattern of use for the BBT blocks is well within the reliability/endurance
specifications.  Do you have some experience on BBTs becoming corrupted, other
than our own development practices, of course :-)

Cheers,

Angus

  reply	other threads:[~2012-01-19  9:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 20:23 [PATCH v3 0/6] NAND BBM + BBT updates Brian Norris
2012-01-09 20:23 ` [PATCH v3 1/6] mtd: nand: add NAND_NO_WRITE_OOB option Brian Norris
2012-01-09 20:23 ` [PATCH v3 2/6] mtd: nand: write bad block marker by default even with BBT Brian Norris
2012-01-09 20:23 ` [PATCH v3 3/6] mtd: nand: erase block before marking bad Brian Norris
2012-01-13 22:42   ` Artem Bityutskiy
2012-01-13 23:07     ` Brian Norris
2012-01-09 20:23 ` [PATCH v3 4/6] mtd: nand: fix SCAN2NDPAGE check for BBM Brian Norris
2012-01-09 20:23 ` [PATCH v3 5/6] mtd: nand: differentiate 1- vs. 2-byte writes when marking bad blocks Brian Norris
2012-01-09 20:23 ` [PATCH v3 6/6] mtd: nand: correct comment on nand_chip badblockbits Brian Norris
2012-01-10  9:44 ` [PATCH v3 0/6] NAND BBM + BBT updates Sebastian Andrzej Siewior
2012-01-10 18:54   ` Brian Norris
2012-01-11 22:28   ` Artem Bityutskiy
2012-01-12  7:58     ` Shmulik Ladkani
2012-01-13 22:12       ` Artem Bityutskiy
2012-01-16 19:35         ` Shmulik Ladkani
2012-01-12  9:09     ` Sebastian Andrzej Siewior
2012-01-13 22:36       ` Artem Bityutskiy
2012-01-16 20:59         ` Woodhouse, David
2012-01-17  8:23           ` Artem Bityutskiy
2012-01-17  8:27             ` Artem Bityutskiy
2012-01-17 11:19         ` Angus CLARK
2012-01-17 13:06           ` Ivan Djelic
2012-01-18 22:18         ` Brian Norris
2012-01-17 10:22     ` Angus CLARK
2012-01-17 13:33       ` Artem Bityutskiy
2012-01-18 22:04       ` Brian Norris
2012-01-19  9:30         ` Angus CLARK [this message]
2012-01-19  9:59           ` Ricard Wanderlof

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=4F17E2C5.2000301@st.com \
    --to=angus.clark@st.com \
    --cc=21cnbao@gmail.com \
    --cc=David.Woodhouse@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=agust@denx.de \
    --cc=arnd@arndb.de \
    --cc=artem.bityutskiy@intel.com \
    --cc=axel.lin@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=cernekee@gmail.com \
    --cc=chuanxiao.dong@intel.com \
    --cc=computersforpeace@gmail.com \
    --cc=dbaryshkov@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dilinger@queued.net \
    --cc=error27@gmail.com \
    --cc=florian@openwrt.org \
    --cc=glecerf@gmail.com \
    --cc=ivan.djelic@parrot.com \
    --cc=jamie@jamieiles.com \
    --cc=jim2101024@gmail.com \
    --cc=joe@perches.com \
    --cc=jonas.gorski@gmail.com \
    --cc=juhosg@openwrt.org \
    --cc=kyungmin.park@samsung.com \
    --cc=leiwen@marvell.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@dominikbrodowski.net \
    --cc=matthieu.castet@parrot.com \
    --cc=maximlevitsky@gmail.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=pewi@gw-instruments.de \
    --cc=robert.jarzmik@free.fr \
    --cc=roman.tereshonkov@nokia.com \
    --cc=s.hauer@pengutronix.de \
    --cc=segooon@gmail.com \
    --cc=shmulik.ladkani@gmail.com \
    --cc=vapier@gentoo.org \
    --cc=w.sang@pengutronix.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;
as well as URLs for NNTP newsgroup(s).