From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sakima.ivy.net ([69.31.131.60]) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1Lx3yl-0005PQ-0X for linux-mtd@lists.infradead.org; Thu, 23 Apr 2009 18:49:11 +0000 Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id CDBAEA80E7 for ; Thu, 23 Apr 2009 14:48:55 -0400 (EDT) To: linux-mtd@lists.infradead.org Subject: Re: Run UBIFS on top of IDE mode NAND disk? References: <000001c9bd90$e726cdb0$0470150a@cisco.com> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Apr_23_14:48:45_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 23 Apr 2009 14:48:55 -0400 In-Reply-To: <000001c9bd90$e726cdb0$0470150a@cisco.com> (Subodh Nijsure's message of "Tue, 14 Apr 2009 23:10:40 -0700") Message-ID: List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --pgp-sign-Multipart_Thu_Apr_23_14:48:45_2009-1 Content-Type: text/plain; charset=US-ASCII >>>>> "sn" == Subodh Nijsure writes: sn> Hi, I have board with 4GB NAND memory chip sn> Can I (Should I) run UBIFS on of it and gain more of sn> wear-levelling or its not worth it? I tried to do this with 16GB USB sticks. There is currently some limit in the mtd-utils around 2GB or 3GB. I think you will have to wait for the 64-bit ioctl patches to go in. I would not expect bad-block remapping of ubifs layer to work at all over an IDE device because IDE error handling is too goofy, and once a bad block is showing through the proprietary wear-leveling layer, the proprietary wear leveler may not be working sanely any more. Probably once the stick/board/whatever-it-is develops one bad block which shows through the wear leveling, you will have to throw it out. The reason I wanted to use it on my USB stick was not only for wear leveling but because ubifs does checksums so I'll know if the cheapo stick is corrupting my data silently. And I think ubi has a scrub feature (which it claims is constantly running in the background, thus much better than 'zpool scrub'. on ZFS they leave it as user's bother to initiate scrubs and thus user's fault rather than the developers' if scrubs cut performance in half). Also I hoped a log-structured filesystem would perform faster for writing and have fewer of the weird problems described here: http://sqlite.org/atomiccommit.html that plague overwrite filesystems like ext3/XFS/JFS/HFS+. I wanted to try it out. In general it looks to me like a really good idea to use the flash filesystems over a layer of proprietary wear-leveling, but supplimenting the proprietary wear leveling might not be the best argument for doing it (because if the proprietary wear leveling is bad in any but a few specific ways(like the old 16MB-chunk way), then you are screwed anyway). There are other good reasons for doing it though. Unfortunately there are scalability issues w.r.t. flash size, and almost no one is doing this yet so it's likely to be clumsy. I've given up on it for a few years. --pgp-sign-Multipart_Thu_Apr_23_14:48:45_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUASfC4F4nCBbTaW/4dAQJLRwP/bpUbXN7iICH0VZJPGxhFsVhbhymriaA7 OnjzBXSk31hXXO1VyoraUjuifPmtDxXQdASCWcbhOz4VVTUPQOeG/V31z+V/MY5U untXoM27wLVN6S8eTXvrrO4yzVMXO+x9ejGf68C0c0aTDuUBYdwZVyvE4m+878HH AtB3QXRp5PA= =Guhb -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Apr_23_14:48:45_2009-1--