From: Artem Bityutskiy <dedekind@infradead.org>
To: Hamish Moffatt <hamish@cloud.net.au>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Wed, 23 Apr 2008 17:09:19 +0300 [thread overview]
Message-ID: <1208959759.11721.76.camel@sauron> (raw)
In-Reply-To: <20080423134254.GA17867@cloud.net.au>
On Wed, 2008-04-23 at 23:42 +1000, Hamish Moffatt wrote:
> On Wed, Apr 23, 2008 at 03:57:47PM +0300, Artem Bityutskiy wrote:
> > On Wed, 2008-04-23 at 22:40 +1000, Hamish Moffatt wrote:
> > > Well I think from past use of "time ubiattach ..." that most of
> > > the missing time is in the attach.
> > Sure, UBI takes most of the time. Its just if you want to save 1.2+ sec,
> > you may try to play with on-flash BBT.
>
> I'm not sure what this means.. ? Instead of having to scan each block
> to check the marker, it has a central table? And that table is created
> once by an initial scan and then added to when UBI declares a block bad?
> How do I access this feature?
Yes.
When your NAND driver is initialized, it scans whole flash and builds
the BBT. Basically, it reads OOB area of each first (and may be second)
page of each eraseblock. The BBT is simply an array with 1 bit per
eraseblock.
You may make it save the BBT on the flash media. So next time you boot,
it reads the BBT from a pre-defined place (e.g., the last eraseblock)
and that's it. It does not scan and does not waste time.
This all is happening in the driver, before UBI starts.
Yes, if UBI marks a block bad, which basically means it calls an MTD
function, the NAND infrastructure changes the on-flash BBT.
But I never used this myself, so my knowledge is theoretical. I just
know others use this and I saw the code in nand_base.c.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-04-23 14:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 16:42 [RFC] slight UBI scan time improvement Artem Bityutskiy
2008-04-22 17:28 ` Bruce_Leonard
2008-04-22 18:07 ` Artem Bityutskiy
2008-04-23 7:15 ` Nancy
2008-04-23 7:32 ` Artem Bityutskiy
2008-04-23 8:01 ` Nancy
2008-04-23 8:16 ` Artem Bityutskiy
2008-04-23 9:07 ` Nancy
2008-04-23 9:13 ` Artem Bityutskiy
2008-04-23 10:51 ` Nancy
2008-04-23 10:57 ` Nancy
2008-04-23 12:24 ` Artem Bityutskiy
2008-04-23 12:23 ` Artem Bityutskiy
2008-04-23 7:38 ` Hamish Moffatt
2008-04-23 8:13 ` Matthieu CASTET
2008-04-23 8:21 ` Artem Bityutskiy
2008-04-23 9:21 ` Matthieu CASTET
2008-04-23 9:27 ` Artem Bityutskiy
2008-04-23 12:40 ` Hamish Moffatt
2008-04-23 12:57 ` Artem Bityutskiy
2008-04-23 13:42 ` Hamish Moffatt
2008-04-23 14:09 ` Artem Bityutskiy [this message]
2008-04-24 1:53 ` Hamish Moffatt
2008-04-24 6:21 ` Artem Bityutskiy
2008-04-24 7:02 ` Hamish Moffatt
2008-04-24 0:10 ` Hamish Moffatt
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=1208959759.11721.76.camel@sauron \
--to=dedekind@infradead.org \
--cc=hamish@cloud.net.au \
--cc=linux-mtd@lists.infradead.org \
/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