All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hamish Moffatt <hamish@cloud.net.au>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Wed, 23 Apr 2008 23:42:54 +1000	[thread overview]
Message-ID: <20080423134254.GA17867@cloud.net.au> (raw)
In-Reply-To: <1208955467.11721.69.camel@sauron>

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?

> > What sort of speed do you get using
> > dd if=/dev/mtdblock9 of=/tmp/foo bs=128K count=64
> > (where mtdblock9 is your raw mtd NAND device). I'm seeing about 6
> > seconds to read that 8Mb, which is quite long I guess.
> I have busybox so stuff like 128K does not work. Here are my results:

Hmm I have busybox (1.9.x) also, 128K works ok for me.

> # time dd if=/dev/mtd4 of=/dev/null bs=131072 count=64
> 64+0 records in
> 64+0 records out
> real    0m 0.28s
> user    0m 0.00s
> sys     0m 0.28s

Very good. It's about 6.1 seconds for me :-(

(Worse on my previous hardware which had compact flash on IDE without a
hardware IDE controller: over 11 seconds.)


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

  reply	other threads:[~2008-04-23 13:43 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 [this message]
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=20080423134254.GA17867@cloud.net.au \
    --to=hamish@cloud.net.au \
    --cc=dedekind@infradead.org \
    --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 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.