Image via Wikipedia
Linux has been slowly but surely establishing itself as the predominant OS in the embedded industry. ABI research report suggested that 23% of Smartphones will be based on Linux by 2013. High-profile industry support from Android and the LiMo foundation has put the spotlight back on embedded Linux. In a previous post, we talked about flash memory and the various layers of flash management. In this post, I will talk about JFFS2, the most popular flash file systems available on the Linux platform JFFS2 The Journaling Flash File System version 2 (JFFS2) is a log-structured file system that was originally designed in 1999. The original JFFS was developed by Axis Communications (and later enhanced by Red Hat) to provide support for NOR flash devices. The current version has been updated to include support for NAND flash. JFFS2 is open-source software, distributed under the terms of GPL license.
1. Portability to Development Environments: Included with the Linux kernel since version 2.4.10, JFFS2 has become a de facto standard flash file system for Linux developers. Today, it is included in most commercial Linux distributions (such as MontaVista and Wind River Linux). Because of this wide distribution and use, it has been integrated into many varying environments and is known to be relatively easy to build.
2. Reliability: As changes are made to the file system, a "log" is built; this log provides information about where a file and its associated metadata are located on the flash chip. As the log is consistently maintained, it will be read back in the event of an unexpected power loss to determine the location of a missing file. Although the log structure provides a level of data reliability, this is accomplished at a cost to performance
3. Support for disk-wide compression: The benefit, or cost, of using compression depends on each specific use case. Compression will be useful in making efficient use of disk space when several text-only or code data (OS, etc.) files are being stored. Media files are already compressed (in *.jpg, *.mpg, or other formats), so the time used to attempt data compression is wasted. It is even possible that media files may take up more space after an unnecessary compression than originally needed. Disk usage and performance for the type and number of files to be maintained must be considered by the device designer in order to determine whether compression will yield a benefit or not.
1. Resource usage: RAM usage by JFFS2 increases in linear proportion to the number of nodes. Hence on large flash volumes, the system resources required by JFFS2 can be very significant
2. System performance: For devices that primarily use the file system for read operations, JFFS2 performance may be acceptable. However, for multi-functional devices whose applications perform a continuous mix of read and write operations, it is likely that the performance of a system using JFFS2 will not pass a rigorous standard. In addition to slow writes, the flash disk mount times of JFFS2 are exceptionally slow and worsen as the amount of data stored increases. Upon start-up after an unexpected power failure, JFFS2 must reconstruct the file system structure from the log. This is a costly operation that requires several seconds - more for volumes that are large or near-capacity. The device will be halted during this check operation, as any data that is stored on the disk will not be ready for use until the start-up completes Informative links on JFFS2
 Details on JFFS2 log structure can be found here http://sourceware.org/jffs2/jffs2-slides-transformed.pdf