All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Matthieu CASTET <matthieu.castet@parrot.com>
Cc: Nancy <nancydreaming@gmail.com>,
	linux-mtd@lists.infradead.org, Bruce_Leonard@selinc.com
Subject: Re: [RFC] slight UBI scan time improvement
Date: Wed, 23 Apr 2008 11:21:04 +0300	[thread overview]
Message-ID: <1208938864.11721.44.camel@sauron> (raw)
In-Reply-To: <480EEFAB.7010304@parrot.com>

Hi,

On Wed, 2008-04-23 at 10:13 +0200, Matthieu CASTET wrote:
> > [    0.950000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
> > [    0.960000] Scanning device for bad blocks
> > [    1.000000] Bad eraseblock 494 at 0x03dc0000
> > [    1.050000] Bad eraseblock 1300 at 0x0a280000
> > [    1.140000] Bad eraseblock 2554 at 0x13f40000
> > [    1.160000] Bad eraseblock 2923 at 0x16d60000
> > [    1.200000] Bad eraseblock 3349 at 0x1a2a0000
> > [    1.230000] Bad eraseblock 3790 at 0x1d9c0000
> > [    6.890000] UBI: attached mtd9 to ubi0
> > 
> > 
> > 
> > Hamish
> 
> Do you know when the bad block scanning finish and the ubi scan start ?

Good point Matthieu. Indeed, _at least_ 1.23 sec is spend in the driver
for scanning against bad eraseblocks to build in-memory bad block table
(BBT). And it is probably more than 1.23 sec. If you start using
on-flash bad block table, this should go away. I never used on-flash
BBT, but I know MTD supports this and for example OLPC has on-flash BBT.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2008-04-23  8:20 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 [this message]
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
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=1208938864.11721.44.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=Bruce_Leonard@selinc.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.com \
    --cc=nancydreaming@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.