All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hamish Moffatt <hamish@cloud.net.au>
To: Artem Bityutskiy <dedekind@infradead.org>,
	Matthieu CASTET <matthieu.castet@parrot.com>,
	Nancy <nancydreaming@gmail.com>,
	linux-mtd@lists.infradead.org, Bruce_Leonard@selinc.com
Subject: Re: [RFC] slight UBI scan time improvement
Date: Thu, 24 Apr 2008 10:10:26 +1000	[thread overview]
Message-ID: <20080424001026.GA13358@cloud.net.au> (raw)
In-Reply-To: <20080423124046.GA16201@cloud.net.au>

On Wed, Apr 23, 2008 at 10:40:46PM +1000, Hamish Moffatt wrote:
> On Wed, Apr 23, 2008 at 11:21:04AM +0300, Artem Bityutskiy wrote:
> > 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.
> 
> Well I think from past use of "time ubiattach ..." that most of
> the missing time is in the attach. 

Here's the evidence:

[    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
[    1.250000] UBI: attaching mtd9 to ubi-1
[    6.890000] UBI: attached mtd9 to ubi0
[    6.900000] UBI: MTD device name:            "gen_nand.0"
[    6.900000] UBI: MTD device size:            512 MiB
[    6.910000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[    6.910000] UBI: logical eraseblock size:    129024 bytes
[    6.920000] UBI: number of good PEBs:        4090
[    6.920000] UBI: number of bad PEBs:         6
[    6.930000] UBI: smallest flash I/O unit:    2048
[    6.930000] UBI: VID header offset:          512 (aligned 512)
[    6.940000] UBI: data offset:                2048
[    6.940000] UBI: max. allowed volumes:       128
[    6.950000] UBI: wear-leveling threshold:    4096
[    6.950000] UBI: number of internal volumes: 1
[    6.960000] UBI: number of user volumes:     4
[    6.960000] UBI: available PEBs:             0
[    6.970000] UBI: total number of reserved PEBs: 4090
[    6.970000] UBI: number of PEBs reserved for bad PEB handling: 40
[    6.980000] UBI: max/mean erase counter: 29/1
[    6.980000] UBI: background thread "ubi_bgt0d" started, PID 641


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

      parent reply	other threads:[~2008-04-24  0:10 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
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 [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=20080424001026.GA13358@cloud.net.au \
    --to=hamish@cloud.net.au \
    --cc=Bruce_Leonard@selinc.com \
    --cc=dedekind@infradead.org \
    --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.