Written by Charles Manning - Originally published at Linuxdevices.org Sept 20th 2002
Designing an effective flash file system is a difficult task and you need to jump through many hoops of fire to get a useful system. Although both are called "Flash", NOR and NAND flash have very different properties. Thus, a flash file system that works with NOR incorporates various mechanisms that are not required for NAND, and NAND needs extra mechanisms not required for NOR. For example, garbage collection performance is largely determined by the erasure time. NOR erases very slowly and thus an effective NOR garbage collection strategy is relatively complex and limits the design options. In comparison NAND erases very quickly; thus these limitations don't apply. Another major difference is that NAND is shipped with marked bad blocks on the device, while NOR chips are shipped defect free. Thus, one expects to encounter some failures in NAND and should design accordingly. This lead me to believe that it would be worth designing a file system specifically for NAND flash, exploiting the features of NAND to simplify the design and catering to NAND specific limitations directly, rather than trying to "bend" NAND to work with an existing file system architecture, or vice versa. The first conceptual design for YAFFS was drawn up in late December 2001. Once the customers bought in to the idea, things progressed rapidly. The first line of code was cut in January 2002. By May 2002 we had the first publicly available CVS code. We now have at least six different companies using or experimenting with YAFFS in embedded or handheld systems. YAFFS is already very stable and is converging rapidly. We expect to see YAFFS-based products shipped before the end of the year.
PHB Summary
YAFFS stands for "yet another flash file system"(*). As far as I am aware, YAFFS is the only file system, under any operating system, that has been designed specifically for use with NAND flash. YAFFS is thus designed to work within the constraints of, and exploit the features of, NAND flash to maximise performance. YAFFS uses journaling, error correction and verification techniques tuned to the way NAND typically fails, to enhance robustness. The result is a file system that exploits low-cost NAND chips and is both fast and robust. YAFFS is highly portable and runs under Linux, ucLinux and Windows CE. YAFFS is an open source project.Why NAND flash?
Embedded and mobile systems are increasingly using NAND flash for storage because it has various advantages over other storage technologies. As always though, life is a compromise and those advantages come with some limitations that need to be addressed to provide a robust flash file system. Hard disks are not a viable storage option for many embedded and handheld systems because they are too big, too fragile and use too much power. For some years now, people have been using common-old NOR flash for file system storage. JFFS and JFFS2 do an excellent job of this for Linux. For storage applications NOR flash is not that great because it is not very dense (ie. not much storage per chip), is costly and is slow to write. NAND flash, on the other hand, is low cost, dense and writes fast, but has other limitations. The most common consumer usage of NAND flash is on SmartMedia cards which are just NAND chips bonded to a carrier card. Consumer use of SmartMedia is driving down NAND prices while driving up densities. The standard SmartMedia file system is FAT based and is thus liable to corruptions due to power failures, crashes and other acts of demonic forces. This raises robustness concerns, particularly in embedded systems where a corrupted file system can kill the device. What's really needed is a journaling file system that is able to work around the limitations of NAND and exploit it for best performance.History
The lead-up to YAFFS started with an investigation into modifying the JFFS2 flash file system to work with NAND flash (**) for some Aleph One customers. It seemed reasonable that the best way to get a file system for NAND flash would be just "tweaking" an existing flash file system. On deeper investigation, it became apparent that designing a new file system specifically for NAND might have some benefits.|
NOR (typical, varies a lot) |
NAND |
|
|
Density |
Up to 32MB chips |
Currently 256MB and growing. |
|
Cost per MB |
$1-$2 |
25c |
|
Access |
Random |
Page oriented with spare area on each page. Sequential access within a page. |
|
Programmability |
Can modify a single bit. |
Very limited re-programming. |
|
Read speed |
50-100nS |
10uS page "seek" + 50nS per byte |
|
Program time |
5uS per byte |
200uS per page |
|
Erasure time |
1s per 64kB block |
2ms per 16kB block |
|
Reliability |
Relatively immune to corruption. No bad blocks. |
Needs error correction. Bad blocks marked when shipped. |
Design approach
Rather than develop and debug code inside the Linux kernel, I took the approach of developing the file system "guts" algorithms - the most complex part -- in a user space program. To achieve this, the code is split into four sections:-
yaffs_guts: The file system algorithms. This code is fully portable C.
-
yaffs_fs.c: Interface layer to the Linux VFS. Can be replaced with a test harness for user space developing of yaffs_guts.c
-
nand interface: wrapper layer between yaffs_guts and the NAND memory access functions. eg. calls Linux mtd layer or RAM emulation layer.
-
Portability functions: wrapper functions for services such as memory allocation etc.