File Systems

This page has information about file systems which are of interest for embedded projects.

Introduction
Most embedded devices use flash memory as storage media. Also, size and bootup time are very important in many consumer electronics products. Therefore, special file systems are often used with differrent features, such as enhanced compression, or the ability to execute files directly from flash.

MTD
Note that flash memory may be managed by the Memory Technology Devices (MTD) system of Linux. See the MTD/Flash FAQ for more information. Most of the filesystems mentioned here are built on top of the MTD system.

UBI
The Unsorted Block Images (UBI) system in the Linux kernel manages multiple logical volumes on a single flash device. It provides a mapping from logical blocks to physical erase blocks, via the MTD layer. UBI provides a flexible partitioning concept which allows for wear-leveling across the whole flash device.

See the UBI page or UBI FAX and Howto for more information.

Embedded Filesystems
Here are some filesystems designed for and/or commonly used in embedded devices:

JFFS2

 * JFFS2 - The Journalling Flash File System, version 2. This is the most commonly used flash filesystem.
 * The maximum size of JFFS2 is 128MB.
 * http://sourceforge.net/projects/mtd-mods has some patches by Alexey Korolev for improvements to JFFS2
 * See the presentation on Alexey's patches at:

CramFS

 * CRAMFS - A compressed read-only file system for Linux. The maximum size of CRAMFS is 256MB.
 * "Linear Cramfs" is the name of a special feature to use uncompressed file, in a linear block layout with the Cramfs file system. This is useful for storing files which can be executed in-place.  For more information on Linear Cramfs, see Application XIP

SquashFS

 * Squash Fs - A (more) compressed read-only file system for Linux. This file system has better compression than JFFS2 or CRAMFS.

YAFFS2

 * YAFFS - Yet Another Flash File System - a file system designed specifically for NAND flash
 * Presentation on YAFFS2 by Wookey at ELC Europe 2007: yaffs.pdf
 * Presentation from CELF Jamboree 17 comparing YAFFS and JFFS2 on 2.6.10: celf_flash.pdf

YAFFS vs. JFFS2 mount time comparisons for 2.6.10
Here are some core results for mount times. (See the Toshiba Jamboree17 presentation for details.)


 * hardware: MIPS, 333 MHZ CPU, with 64 MB NAND Flash.
 * kernel: 2.6.10 +EBS patch +YAFFS (20061128 version).
 * JFFS2 compression option is disabled.
 * Key:
 * “Initial”: Time for mounting when the mount is just after launching “flash_eraseall”.
 * "1000 files”: Time for mounting after creating 1000 files (one file size is 33554 bytes.)
 * “JFFS2+EBS” needs to check EBS, and then it does start to scan the blocks normally. Therefore, “Initial” mount time is a little bit slow.

LogFS
JFFS2 for most uses, but focuses more on the large devices.
 * logfs - LogFS is a scalable flash filesystem. It is aimed to replace

Matt Mackall writes (in July of 2007):

LogFS is a filesystem designed to support large volumes on FLASH. It uses a simple copy-on-write update process to ensure consistency (the "log" in the name is a historical artifact). It's easily the most modern and scalable open-source FLASH filesystem available for Linux and it's well on its way to being accepted in the mainline tree.

Scott Preece writes:

The big win for LogFS (in my limited knowledge of it) is that it stores its tree structure in the media, rather than building it in memory at mount time. This significantly reduces both startup time and memory consumption. This becomes more important as the size of the flash device increases. Read more in LWN (http://lwn.net/Articles/234441) and linux.com (http://www.linux.com/articles/114295).

Some newer flash memory, like MLC (multi-level cell), are not well supported.

LogFS now has it's own mailing list: see http://logfs.org/cgi-bin/mailman/listinfo/logfs

AXFS

 * AXFS - Advanced XIP File System
 * This file system is designed specifically to support Execute-in-place operations

ABISS
The Active Block I/O Scheduling System is a file system designed to be able to provide real-time features for file system I/O activities.

See ABISS

UnionFS
Sometimes it is handy to be able to overlay file systems on top of each other. For example, it can be useful in embedded products to use a compressed read-only file system, mounted "underneath" a read/write file system. This give the appearance of a full read-write file system, while still retaining the space savings of the compressed file system, for those files that won't change during the life of the product.

UnionFS is a project to provide such a system (providing a "union" of multiple file systems).

See http://www.filesystems.org/project-unionfs.html

See also union mounts, which are described at http://lkml.org/lkml/2007/6/20/18 (and also in Documentation/union-mounts.txt in the kernel source tree - or will be, when this feature is merged.)

Multi-media file systems

 * XPRESS file system - [See OLS 2006 proceedings, presentation by Joo-Young Hwang]
 * I found out at ELC 2007 that this FS project was recently suspended internally at Samsung