From: Artem Bityutskiy <dedekind1@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Brian Norris <computersforpeace@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
Kulikov Vasiliy <segooon@gmail.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Peter Wippich <pewi@gw-instruments.de>,
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>,
Barry Song <21cnbao@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>,
Adrian Hunter <adrian.hunter@intel.com>,
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, 12 Jan 2012 00:28:45 +0200 [thread overview]
Message-ID: <1326320928.2338.37.camel@koala> (raw)
In-Reply-To: <4F0C086A.5070608@linutronix.de>
On Tue, 2012-01-10 at 10:44 +0100, Sebastian Andrzej Siewior wrote:
> and I am still not convinced that it is a good idea to provide one
> information in two places. It seems to be redundant. If there are other
> people supporting this, I am not in your way.
NANDs become less and less reliable - they suffer from all kinds of read
and write disturb issues, unstable bits, etc. Do you trust MTD's
on-flash BBT which was created for the old reliable flashes? I don't
really trust it. I have a feeling that it is very real to have the BBT
corrupted because of read/write disturb - we read it rarely.
In my view, OOB BB markers is the primary, reliable, and simple
mechanism. And BBT is just an additional optimization to speed up system
startup.
So in general I support Brian's efforts. However, I am not sure that
Brian's decision to first mark block as bad in BBT than in OOB is the
right one. I have a feeling that the opposite way is correct. And it
looks like this will almost automatically solve the possible issue of
getting BBT and OOB out-of-sync due to a power cut while making a block
as bad. At least for the software I know: JFFS2, UBI, user-space tools
like ubiformat - I'll refer it just as "SW".
Indeed, when we mark a block as bad?
1. When we get erase error. Well, if SW erases a block, it does not care
of the contents. This means that if after the reboot SW will re-try
erasing it. And if the block is bad, and previously the erasure failed,
it will fail again, and SW will mark it as bad again.
2. When we get a write error. The SW recovers useful data from the
eraseblock, then tries to mark it bad. Well, UBI will first try to
torture it, but this is a not essential detail. Anyway, if we get a
power cut - the situation is the same - SW will try to erase this block
and write to it, will get errors again and will mark it as bad.
I guess we also need to read oob before writing it when we are marking a
block as bad - just in case it is already marked as bad in OOB.
Comments? If this does not make sense - I have a good excuse - it is
late and I am very sleepy :-)
next prev parent reply other threads:[~2012-01-11 22:28 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 [this message]
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
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=1326320928.2338.37.camel@koala \
--to=dedekind1@gmail.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=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