Date: Mon, 31 Mar 2008 10:36:09 -0700 From: "Martin Fouts" <mfouts@danger.com> To: "Matthew Dillon" <dillon@apollo.backplane.com>, "Christopher Arnold" <chris@arnold.se>, <arch@freebsd.org> Subject: RE: Flash disks and FFS layout heuristics Message-ID: <B95CEC1093787C4DB3655EF330984818051D03@EXCHANGE.danger.com> In-Reply-To: <200803310135.m2V1ZpiN018354@apollo.backplane.com> References: <20080330231544.A96475@localhost> <200803310135.m2V1ZpiN018354@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I came late to this discussion, so pardon me if I'm repeating stuff that's already been discussed. You can guess a lot from vendor specs, but NAND flash requires experience before you understand the nuances; especially since the vendors tend not to document most of what you need to know to get good performance and reliability from a flash device. There are, basically, two approaches to using NAND devices. What PHK calls "flash adapation layer" or, sometimes, "flash translation layer" is widely used in devices that are meant to be seen as removable ms-dos file system devices, such as almost every USB NAND based flash device on the market. It is also used in at least two commercial flash file systems intended for embedded flash. It is also an approach available to the Linux MTD layer, although not used by any of the Linux filesystems. This approach works well enough for specific usage patterns and you will find several successful embedded devices on the CE market place that use it. The second approach is to have a 'flash aware filesystem', which understand the write/read/erase properties of NAND flash parts. There are three variants on this approach that I'm aware of. The first takes a 'traditional' filesystem like FFS and, in effect, adds a flash translation layer. The second takes a log-like file system and adapts its GC to NAND. The third approach is to write a file system specific to NAND devices from scratch. PalmOS Garnet's NAND file system is an example of the first. The modified version of LFS that Mike Chen and I did for PalmOS Cobalt is an example of the second. The MTD based file system jffs2 is an example of the third, and a cautionary tale for those who would write their own. In addition to the various points Matt Dillon has figured out from reading specs, there are several features of NAND parts that I haven't seen mentioned here that play a fairly important role in designing file systems around them. These include, but are probably not limited to: 1) Large page versus small page NAND 2) Broken or poorly performing hardware, especially ECC generation and write verification 3) Adjacent write effect Some interesting properties to take into account when designing a NAND file system: 1) No block can be assumed good, which means you have to scan the device to find your metadata starting point at boot time. 2) Small page NAND has less 'spare' available in the spare region than large page NAND, which means that you can do optimizations for large page nand that you can't for small. 3) write-back caching of writes makes NAND parts less reliable
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B95CEC1093787C4DB3655EF330984818051D03>