From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Steven Munk Østergaard" <sml@rosetechnology.dk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: How does UBI FS handle invalid PEB on nand flash
Date: Wed, 27 Jun 2012 17:27:59 +0300 [thread overview]
Message-ID: <1340807279.3070.39.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <4FE872C3.1020402@rosetechnology.dk>
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
On Mon, 2012-06-25 at 16:16 +0200, Steven Munk Østergaard wrote:
> Been reading all of the available documentation on UBI and UBIFS but I
> cannot find a clear statement on how UBIFS handles production marked
> invalid PEB's, and if their location is saved; So when a format is done,
> this information is not lost.
>
> is there a way to make sure UBIFS allways checks for production marked
> invalid PEB's when a device is started the first time?
UBIFS / UBI do not store information about bad eraseblocks. This is
handled by MTD. UBI may only query "if this eraseblock is good?" or mark
an eraseblock as bad. The bad block management is done at the MTD level.
Traditionally, the bad block marker is stored in the OOB of the first
page, but there are variations. When MTD initalizes, it scans the entire
flash and reads all OOBs, and builds the in-memory bad block table. The
other option is on-flash bad block table, which is typically stored at
the 2 last good eraseblocks of the flash (AFAIR) and stores information
about all bad eraseblocks. In this case you do not need scanning, which
is faster. There are flashes which cannot store bad/good status in OOB,
they use the on-flash BBT.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-06-27 14:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 14:16 How does UBI FS handle invalid PEB on nand flash Steven Munk Østergaard
2012-06-27 14:27 ` Artem Bityutskiy [this message]
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=1340807279.3070.39.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sml@rosetechnology.dk \
/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