From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from risingsoftware01.propagation.net ([66.221.33.65]) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1JilqD-00058O-DV for linux-mtd@lists.infradead.org; Mon, 07 Apr 2008 07:32:33 +0000 Received: from c122-107-142-134.eburwd5.vic.optusnet.com.au ([122.107.142.134] helo=noddy.cloud.net.au) by risingsoftware01.propagation.net with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JilqC-0000OR-4f for linux-mtd@lists.infradead.org; Mon, 07 Apr 2008 02:32:32 -0500 Received: from hamish by noddy.cloud.net.au with local (Exim 4.69) (envelope-from ) id 1Jilq7-0001gx-6B for linux-mtd@lists.infradead.org; Mon, 07 Apr 2008 17:32:27 +1000 Date: Mon, 7 Apr 2008 17:32:27 +1000 From: Hamish Moffatt To: linux-mtd@lists.infradead.org Subject: Re: choosing a file system to use on NAND/UBI Message-ID: <20080407073227.GA6317@cloud.net.au> References: <20080328010403.GB23610@cloud.net.au> <1206686024.3856.57.camel@sauron> <20080407051259.GA3584@cloud.net.au> <1207552429.8040.33.camel@sauron> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1207552429.8040.33.camel@sauron> List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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