Difference between revisions of "File Systems"

From eLinux.org
Jump to: navigation, search
(YAFFS2: add link to wookey presentation)
(YAFFS vs. JFFS2 mount time comparisons for 2.6.10)
Line 28: Line 28:
  
 
==== YAFFS vs. JFFS2 mount time comparisons for 2.6.10 ====
 
==== YAFFS vs. JFFS2 mount time comparisons for 2.6.10 ====
Here are some core results for mount times:
+
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.
 
* hardware: MIPS, 333 MHZ CPU, with 64 MB NAND Flash.
 
* kernel: 2.6.10 +EBS patch +YAFFS (20061128 version).
 
* kernel: 2.6.10 +EBS patch +YAFFS (20061128 version).

Revision as of 09:59, 7 November 2007

This page has information about file systems which are of interest to CE Linux Forum members.

Embedded Filesystems

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.

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.
  • See below for measurements

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.
JFFS2 JFFS2+EBS YAFFS
Initial 0.93 sec 1.12 sec 0.27 sec
1000 files 7.34 sec 1.06 sec 2.52 sec

LogFS

  • logfs - LogFS is a scalable flash filesystem. It is aimed to replace

JFFS2 for most uses, but focuses more on the large devices.

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.

AXFS

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


Special-purpose Filesystems

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 proj3ect 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.)

Other projects

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

flash logical volume management

  • UBI http://www.linux-mtd.infradead.org/faq/ubi.html manages multiple logical volumes on a single flash device, specifically supporting NAND flash devices. UBI provides a flexible partitioning concept which still allows for wear-levelling across the whole flash device.