JFFS2
| Developer | David Woodhouse |
|---|---|
| Full name | Journalling Flash File System version 2 |
| Introduced | (Linux 2.4.10) |
| Features | |
| Transparent compression | zlib, rubin and rtime |
| Supported operating systems | Linux |
Journalling Flash File System version 2 or JFFS2 is a log-structured file system for use with flash memory devices.[1] It is the successor to JFFS. JFFS2 has been included in the Linux kernel since the 2.4.10 (2001-09-23) release. JFFS2 is also available for a few bootloaders, like Das U-Boot, Open Firmware, the eCos RTOS and the RedBoot. Most prominently JFFS2 is used in OpenWrt.[2]
At least four file systems have been developed as JFFS2 replacements: F2FS, LogFS, UBIFS, and YAFFS.
Contents |
Features [edit]
JFFS2 introduced:
- Support for NAND flash devices. 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. Four algorithms are available: zlib, rubin, rtime, and lzo.
- Better performance. JFFS treated the disk as a purely circular log. This generated a great deal of unnecessary I/O. The garbage collection algorithm in JFFS2 makes this mostly unnecessary.
Design [edit]
As with JFFS, changes to files and directories are "logged" to flash in nodes, 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.
- dirent nodes: 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 as valid when they are created, and become obsolete when a newer version has been created elsewhere.
Unlike JFFS, however, there is no circular log. Instead, JFFS2 deals in blocks, 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. A clean block is one that contains only valid nodes. A dirty block contains at least one obsolete node. A free block contains no nodes.
The garbage collector runs in the background, turning dirty blocks into free blocks. It does this by copying valid nodes to a new block and skipping obsolete ones. That done, it erases the dirty block and tags it with a special marker designating it as a free block (to prevent confusion if power is lost during an erase operation).
To make wear-levelling more even and prevent erasures from being too concentrated on mostly-static file systems, the garbage collector will occasionally also consume clean blocks.
Disadvantages [edit]
- All nodes must still be scanned at mount time. This is slow and is becoming an increasingly serious problem as flash devices scale upward into the gigabyte range.
- 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 [edit]
External links [edit]
- Red Hat JFFS2 site
- JFFS: The Journalling Flash File System by David Woodhouse (PDF)
- JFFS2 official mailing list
- JFFS2 FAQ
References [edit]
- ^ JFFS2, mainly designed for raw flash, not for block devices like hard drives, USB sticks, CF cards etc. (block2mtd)
- ^ http://wiki.openwrt.org/doc/techref/flash.layout
