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

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

+

+

It is possible to tune the amount of compression when running mksquashfs. The -b option allows you to specify the block size. A smaller block size generally gives less compression and a larger -b option gives more compression. However there is a downside to this. Data is read from the flash using blocks. So if you use a block size of 128k, and you need a page of 4k, still the compressed equivalent of 128k data will be read from flash. As 128k comprises 32 pages, it will result in 32 pages being read into the buffer cache, even though at the moment of reading you only need one. Often the other 31 pages will be needed as well, but if not you wasted some tiem to read and decompress the unused data. Also you got some unneeded data in the buffer cache (possibly the system even had to kick used pages from the cache in order to make room for these 31 pages).

+

+

If you care for the smallest filesystem you probably want to go with the largest block size. However, if your primary concern is performance you might want to experiment a little bit to see what works out best for you.

=== YAFFS2 ===

=== YAFFS2 ===

Revision as of 16:13, 9 November 2008

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.

Partitioning

The kernel requires at least one "root" file system, onto which
other file systems can be mounted. In non-embedded systems, often only a single
file system is used. However, in order to optimize limited resources (flash, RAM,
processor speed, boot up time), many embedded systems
break the file system into separate parts, and put each part on it's own partition (often in
different kinds of storage.

For example, a developer may wish to take all the read-only files of the system, and put
them into a compressed, read-only file system in flash. This will consume the least amount
of space on flash, at the cost of some read-time performance (for decompression).

Another configuration might have executable files stored uncompressed on flash, so that
they can be executed-in-place, which saves RAM and boot-up time (with a potential small
loss of performance).

For writable data, if the data does not need to be persistent, sometimes a ramdisk
is used. Depending on the performance needs and the RAM limits, the file data may be
compressed or not.

There is no single standard for interleaving the read-only and read-write portions of the
file system. This depends heavily on the set of embedded applications used for the
project.

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.

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

romfs

SquashFS

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

It is possible to tune the amount of compression when running mksquashfs. The -b option allows you to specify the block size. A smaller block size generally gives less compression and a larger -b option gives more compression. However there is a downside to this. Data is read from the flash using blocks. So if you use a block size of 128k, and you need a page of 4k, still the compressed equivalent of 128k data will be read from flash. As 128k comprises 32 pages, it will result in 32 pages being read into the buffer cache, even though at the moment of reading you only need one. Often the other 31 pages will be needed as well, but if not you wasted some tiem to read and decompress the unused data. Also you got some unneeded data in the buffer cache (possibly the system even had to kick used pages from the cache in order to make room for these 31 pages).

If you care for the smallest filesystem you probably want to go with the largest block size. However, if your primary concern is performance you might want to experiment a little bit to see what works out best for you.

YAFFS2

YAFFS - Yet Another Flash File System - a file system designed specifically for NAND flash

LogFS

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

This file system is designed specifically to support Execute-in-place operations. It uses a bi-phased approach. The first phase is to have the filesystem in flash and run it to collect profile data, stating what pages are used. In the second phase you build a filesystem using these profile data. This filesystem makes all pages metioned in the profile file as XIP data, which can then will be loaded to RAM upon mounting (and executed as XIP). It is also possible to put the XIP pages in NOR flash and run them from there.

PRAMFS

The Persistent/Protected RAM Special Filesystem (PRAMFS) is a full-featured read/write filesystem that has been designed to work with fast I/O memory, and if the memory is non-volatile, the filesystem will be persistent. In addition, it has Execute-in-place support.

NFS

Due to space constraints on embedded devices, it is common during development to use
a network file system for the root filesystem for the target. This allows the target to
have a very large area where full-size binaries and lots of development tools can be placed
during development. One drawback to this approach is that the system will need to
be re-configured with local file systems (and most likely re-tested) for final
product shipment, at some time during the development cycle.

An NFS client can be built into the Linux kernel, and the kernel
can be configured to use NFS as the root filesystem. This requires support for networking,
and mechanisms for specifying the IP address for the target, and the path to the filesystem
on the NFS host. Also, the host must be configured to run an NFS server. Often, the host
also provides the required address and path information to the target board by running
a DHCP server.

See the the file Documentation/nfsroot.txt in the Linux kernel source for more information
about mounting an NFS root filesystem with the kernel.

Mounting the root filesystem

The root filesystem is mounted by the kernel, using a kernel command line option.
Other file systems are mounted from user space, usually by init scripts or an
init program, using the 'mount' command.

The following are examples of command lines used for mounting a root filesystem
with Linux:

Use the first partition on the first IDE hard drive:

root=/dev/hda1

or in later kernels:

root=/dev/sda1

Use NFS root filesystem (kernel config must support this)

root=/dev/nfs

(Usually you need to add some other arguments to make sure
the kernel IP address gets configured, or to specify the
host NFS path.)

Use flash device partition 2:

root=/dev/mtdblock2

[FIXTHIS - should probably mention initrd's here somewhere]

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.

Layered Filesystems

Layered filesystems enable you to mount read-only media and still have the possibility to write to it. At least, the writing part will end up somewhere else, which is transparantly handled by the layered filesystem. It has been around for quite some time and below are some examples of filesystems already usable on (embedded) Linux systems out-of-the-box.

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