From: Artem Bityutskiy <dedekind@infradead.org>
To: Konstantin Kletschke <lists@ku-gbr.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: General performance of NAND operations i.e mount and ls
Date: Thu, 06 Sep 2007 11:27:21 +0300 [thread overview]
Message-ID: <1189067241.14370.23.camel@sauron> (raw)
In-Reply-To: <20070906081215.GA5693@anita.doom>
Hi,
On Thu, 2007-09-06 at 10:12 +0200, Konstantin Kletschke wrote:
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V
> 8-bit)
> 2 NAND chips detected
> Scanning device for bad blocks
> Bad eraseblock 1838 at 0x0e5c0000
> Bad eraseblock 2697 at 0x15120000
> Bad eraseblock 3888 at 0x1e600000
> Bad eraseblock 4338 at 0x21e40000
> Bad eraseblock 4501 at 0x232a0000
> Bad eraseblock 8534 at 0x42ac0000
> Bad eraseblock 14308 at 0x6fc80000
> Bad eraseblock 14329 at 0x6ff20000
> Bad eraseblock 16142 at 0x7e1c0000
> Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit":
> 0x00000000-0x80000000 : "NAND Flash"
If you useed on-flash BBT, you'd avoid scanning and make this phase
faster. But the improvement would be nothing comparing to JFFS2's delay.
> Mounting lasts 20 seconds, is that a reasonable time for jffs2 on 2GiB
> NAND? May be...
Well, JFFS2 scans on mount, so no wonder it is that long. Summary should
improves the situation - do you have it enabled?
> # time mount -t jffs2 /dev/mtdblock4 /mnt
> JFFS2 notice: (186) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0
> of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> real 0m 19.03s
> user 0m 0.01s
> sys 0m 19.01s
>
> But the fist/initital ls takes half an hour, is this okay or are your
> faster?
It's because you use -a, which causes stat() to be called for each file.
Stat causes read_inode(), which is slow. It builds file's fragtree,
which means it reads and checks each of its nodes. So the larger is the
file the longer it takes to stat() it for the first time (the second and
later are cached).
> What are your experiences on flash devices?
I do not think you may make JFFS2 work faster on such big flash with
such big files, at least it will be difficult and would require core
jffs2 changes.
I'd suggest you to try UBIFS - it must be faster. We would also be
interested to get a feedback.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-09-06 8:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 8:12 General performance of NAND operations i.e mount and ls Konstantin Kletschke
2007-09-06 8:27 ` Artem Bityutskiy [this message]
2007-09-06 8:44 ` Konstantin Kletschke
2007-09-06 9:11 ` Artem Bityutskiy
2007-09-06 9:37 ` Konstantin Kletschke
2007-09-06 10:53 ` Artem Bityutskiy
2007-09-06 11:21 ` Artem Bityutskiy
2007-09-06 11:11 ` Artem Bityutskiy
2007-09-06 16:03 ` Konstantin Kletschke
2007-09-07 5:47 ` Artem Bityutskiy
2007-09-07 7:44 ` Konstantin Kletschke
2012-06-25 12:01 ` JFFS2 CRC problems Stefan Roese
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=1189067241.14370.23.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=lists@ku-gbr.de \
/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