General performance of NAND operations i.e mount and ls

Artem Bityutskiy dedekind at infradead.org
Thu Sep 6 04:27:21 EDT 2007


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 (Битюцкий Артём)




More information about the linux-mtd mailing list