Re: choosing a file system to use on NAND/UBI

Hamish Moffatt
2008-04-07T07:32:33Z

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>