From: Hamish Moffatt <hamish@cloud.net.au>
To: linux-mtd@lists.infradead.org
Subject: Re: choosing a file system to use on NAND/UBI
Date: Mon, 7 Apr 2008 17:32:27 +1000 [thread overview]
Message-ID: <20080407073227.GA6317@cloud.net.au> (raw)
In-Reply-To: <1207552429.8040.33.camel@sauron>
On Mon, Apr 07, 2008 at 10:13:49AM +0300, Artem Bityutskiy wrote:
> On Mon, 2008-04-07 at 15:12 +1000, Hamish Moffatt wrote:
> > Just to finish this old discussion, it's a 512Mb SLC part. ie not very
> > big. I have tried UBIFS and I am very pleased with it. Performance is
> > much better than JFFS2, which was slow to mount and slow during early
> > reads (even when the image was processed with sumtool).
>
> "Mb" looks like Maga-bit, is that right?
Sorry I should've said 512MiB perhaps: 512 megabytes.
UBI attach time appears to be about 6 seconds.
[ 0.960000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
[ 0.970000] Scanning device for bad blocks
[ 1.020000] Bad eraseblock 494 at 0x03dc0000
[ 1.110000] Bad eraseblock 1300 at 0x0a280000
[ 1.240000] Bad eraseblock 2554 at 0x13f40000
[ 1.280000] Bad eraseblock 2923 at 0x16d60000
[ 1.330000] Bad eraseblock 3349 at 0x1a2a0000
[ 1.370000] Bad eraseblock 3790 at 0x1d9c0000
[ 1.410000] cmdlinepart partition parsing not available
[ 7.210000] UBI: attached mtd9 to ubi0
[ 7.210000] UBI: MTD device name: "gen_nand.0"
[ 7.220000] UBI: MTD device size: 512 MiB
[ 7.220000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 7.230000] UBI: logical eraseblock size: 129024 bytes
[ 7.240000] UBI: number of good PEBs: 4090
[ 7.240000] UBI: number of bad PEBs: 6
[ 7.250000] UBI: smallest flash I/O unit: 2048
[ 7.250000] UBI: VID header offset: 512 (aligned 512)
[ 7.260000] UBI: data offset: 2048
[ 7.260000] UBI: max. allowed volumes: 128
[ 7.270000] UBI: wear-leveling threshold: 4096
[ 7.270000] UBI: number of internal volumes: 1
[ 7.270000] UBI: number of user volumes: 4
[ 7.280000] UBI: available PEBs: 0
[ 7.280000] UBI: total number of reserved PEBs: 4090
[ 7.290000] UBI: number of PEBs reserved for bad PEB handling: 40
[ 7.290000] UBI: max/mean erase counter: 41/1
[ 7.300000] UBI: background thread "ubi_bgt0d" started, PID 619
Mounting the 128MiB root volume (ubifs) is taking 0.35 seconds:
# time mount -o ro -t ubifs ubi0:rootA /mnt
[ 404.390000] UBIFS: mounted UBI device 0, volume 0
[ 404.400000] UBIFS: mounted read-only
[ 404.400000] UBIFS: minimal I/O unit size: 2048 bytes
[ 404.400000] UBIFS: logical eraseblock size: 129024 bytes (126 KiB)
[ 404.410000] UBIFS: file system size: 132894720 bytes (129780 KiB, 126 MiB, 1030 LEBs)
[ 404.420000] UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
[ 404.430000] UBIFS: data journal heads: 1
[ 404.430000] UBIFS: default compressor: zlib
real 0m 0.34s
user 0m 0.00s
sys 0m 0.35s
which is fine. Although if there was any way to speed it up I would be
interested, particularly the UBI attach time.
I switched my UBIFS from the default lzo to zlib compression, as the
resulting images (from mkfs.ubifs) were smaller. Is there any reason to
prefer the default lzo?
thanks,
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
next prev parent reply other threads:[~2008-04-07 7:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 1:04 choosing a file system to use on NAND/UBI Hamish Moffatt
2008-03-28 6:33 ` Artem Bityutskiy
2008-04-07 5:12 ` Hamish Moffatt
2008-04-07 7:13 ` Artem Bityutskiy
2008-04-07 7:32 ` Hamish Moffatt [this message]
2008-04-07 7:48 ` Hamish Moffatt
2008-04-07 7:56 ` Artem Bityutskiy
2008-04-07 11:20 ` Hamish Moffatt
2008-04-07 12:15 ` Artem Bityutskiy
2008-04-07 12:16 ` Artem Bityutskiy
2008-04-07 12:22 ` Hamish Moffatt
2008-04-07 12:44 ` Artem Bityutskiy
2008-04-07 15:31 ` Jamie Lokier
2008-04-08 10:21 ` Hamish Moffatt
2008-04-07 8:41 ` Artem Bityutskiy
2008-04-08 7:07 ` Artem Bityutskiy
2008-03-28 7:22 ` Adrian Hunter
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=20080407073227.GA6317@cloud.net.au \
--to=hamish@cloud.net.au \
--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.