JFFS2

Journalling Flash File System version 2orJFFS2is alog-structured file systemfor use withflash memorydevices.It is the successor toJFFS.JFFS2 has been included into theLinux kernelsince September 23, 2001, when it was merged into theLinux kernel mainlineas part of the kernel version 2.4.10 release. JFFS2 is also available for a fewbootloaders,likeDas U-Boot,Open Firmware,theeCosRTOS, theRTEMSRTOS, and theRedBoot.Most prominent usage of the JFFS2 comes fromOpenWrt.

JFFS2

Developer(s)	David Woodhouse
Full name	Journalling Flash File System version 2
Introduced	September 23, 2001(2001-09-23)withLinux2.4.10
Features
Transparent compression	zlib,rubin and rtime
Other
Supported operating systems	Linux

At least three file systems have been developed as JFFS2 replacements:LogFS,UBIFS,andYAFFS.

Features

JFFS2 introduced:

• Support forNAND flashdevices. This involved a considerable amount of work as NAND devices have a sequential I/O interface and cannot be memory-mapped for reading.
• Hard links. This was not possible in JFFS because of limitations in the on-disk format.
• Compression. Five algorithms are available:zlib,rubin, lzma, rtime, andlzo.
• Better performance. JFFS treated the disk as a purely circular log. This generated a great deal of unnecessary I/O. Thegarbage collectionalgorithmin JFFS2 makes this mostly unnecessary.

Design

As with JFFS, changes to files and directories are "logged" to flash innodes,of which there are two types:

• inodes:a header with file metadata, followed by a payload of file data (if any). Compressed payloads are limited to one page.
• direntnodes: directory entries each holding a name and an inode number. Hard links are represented as different names with the same inode number. The special inode number 0 represents an unlink.

As with JFFS, nodes start out asvalidwhen they are created, and becomeobsoletewhen a newer version has been created elsewhere.

Unlike JFFS, however, there is no circular log. Instead, JFFS2 deals inblocks,a unit the same size as the erase segment of the flash medium. Blocks are filled, one at a time, with nodes from bottom up. Acleanblock is one that contains onlyvalidnodes. Adirtyblock contains at least oneobsoletenode. Afreeblock contains no nodes.

Thegarbage collectorruns in the background, turningdirtyblocks intofreeblocks. It does this by copyingvalidnodes to a new block and skippingobsoleteones. That done, it erases thedirtyblock and tags it with a special marker designating it as afreeblock (to prevent confusion if power is lost during an erase operation).

To makewear-levellingmore even and prevent erasures from being too concentrated on mostly-static file systems, the garbage collector will occasionally also consumecleanblocks.

Disadvantages

Due to its log-structured design, JFFS2's disadvantages include the following:

• All nodes must still be scanned atmounttime. This is slow and is becoming an increasingly serious problem as flash devices scale upward into theterabyterange. To overcome this issue, theErase Block Summary(EBS) was introduced in version 2.6.15 of the Linux kernel. EBS is placed at the end of each block and updated upon each write to the block, summarizing the block's content; during mounts, EBS is read instead of scanning whole blocks.
• Writing many small blocks of data can even lead to negative compression rates, so it is essential for applications to use large write buffers.
• There is no practical way to tell how much usable free space is left on a device since this depends both on how well additional data can be compressed, and the writing sequence.

See also

• List of file systems
• UBIFS
• NILFS
• F2FS

External links

• JFFS2 website
• JFFS: The Journalling Flash File Systemby David Woodhouse (PDF)
• JFFS2 official mailing list
• JFFS2 FAQ