全部博文（327）
分类： LINUX
2010-06-05 16:53:12
Most embedded devices use 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.
Note that flash memory may be managed by the Memory Technology Devices (MTD) system of Linux. See the for more information. Most of the filesystems mentioned here are built on top of the MTD system.
MTD stands for
The (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 page or for more information.
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.
Here are some filesystems designed for and/or commonly used in embedded devices, sorted in alphabetical order:
From March 2006 :
INTRODUCING INITRAMFS, A NEW MODEL FOR INITIAL RAM DISKS This clear, technical article introduces initramfs, a Linux 2.6 feature that enables an initial root filesystem and init program to reside in the kernel's memory cache, rather than on a ramdisk (as with initrd filesystems). Compared to initrd, intramfs can increase boot-time flexibility, memory efficiency, and simplicity, the author says. One especially interesting feature for embedded Linux developers is that relatively simple, deeply embedded systems can use initramfs as their sole filesystem.
All of the papers by Nicholas McGuire at: http://linuxdevices.com/news/NS6374541663.html
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 () and linux.com ().
Some newer flash memory, like MLC (multi-level cell), are not well supported.
LogFS now has it's own mailing list: see
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.
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.
Info on the PRAMFS specification can be found at
is a (more) compressed read-only file system for Linux. This file system has better compression than JFFS2 or CRAMFS. After spending a long time outside of the mainline kernel, Squashfs have finally been merged and released with .
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 (and that could even be applying no compression at all! Mksquashfs has options: -noInodeCompression, -noDataCompression and –noFragmentCompression to control this). If you also applied function reordering (see a large block size will probably work out well for you.
The table below gives an idea of the amount of compression that is achieved by the various block sizes. Input was a root filesystem of an embedded device.
| size | compression | |
|---|---|---|
| Initial | 53128K | 100 % |
| 4K | 17643K | 33.2 % |
| 8K | 16572K | 31.2 % |
| 16K | 15780K | 29.7 % |
| 32K | 15204K | 28.6 % |
| 64K | 14812K | 27.9 % |
A presentation on Squash FS by Phillip Lougher at ELC Europe 2008: and .
is a filesystem that works on top of volumes
YAFFS2 is simple, portable, reliable and self-contained. It is widely used in embedded OSes other than Linux, and can also be used stand-alone without an OS, e.g. in bootloaders. When used with Linux it can use MTD or its own flash driver. Similarly it can use the VFS or its own posix layer. It is log-structured, and single-threaded. It does not do compression itself - either compress the data itself or use squashfs on top of YAFFS2.
YAFFS2 is designed to boot quickly (insofar as a log-structured FS that has to scan the flash can). It uses checkpointing so that if a partition was unmounted cleanly then there is no need to rescan the flash on power-up. All the features of the FS are configuable so you can trade off things like maximum file/partition size, flash block size, file granulaity etc. Data is written straight through to the flash except for caching to ensure efficienct use of blocks. YAFFS2 normally uses the OOB are of the flash for its metadata, allowing faster booting as only the OOB needs to be read for flash scan. It can keep its metadata inside the main page area at the expense of some speed.
Despite having been in use on Linux in real products since 2004 it has not yet made it to the mainline.
YAFFS2 is GPLed, but is also available under dual-licensing terms for use in non-free contexts from Aleph One Ltd.
Here are some core results for mount times. (See the Toshiba Jamboree17 presentation for details.)
| 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 |
It is unclear whether or not these data are made with a jffs2 driver that has the erase block summary patch applied. This patch is part of the jffs2 driver since 2005-09-07. A patch for an earlier version can be found at: (or try your luck at ).
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:
(Usually you need to add some other arguments to make sure the kernel IP address gets configured, or to specify the host NFS path.)
[FIXTHIS - should probably mention initrd's here somewhere]
Since it is not possible to use the loopback device to mount JFFS2 images, mtdram needs to be used instead. Usually three modules are needed to get it working:
modprobe mtdram total_size=16384
modprobe mtdblock
modprobe jffs2
Depending on the target's endianess the image file might need conversion to PC endianess. jffs2dump from the MTD tools can be used to archive this.
jffs2dump -b -c -e
The final image can be copied to the block device using dd.
dd if=of=/dev/mtdblock0
Mounting is done in the usuall way.
mount /dev/mtdblock0 /tmp/jffs2 -t jffs2
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
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.
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
See also union mounts, which are described at (and also in Documentation/union-mounts.txt in the kernel source tree - or will be, when this feature is merged.)
Another UnionFS. Go to for more details.
minifo = mini fanout overlay file system.
Go to for more details.
Apparently this is not maintained any more. Last information is from 2005.
A mountable virtual filesystem that allows accessing mediawiki based sites as regular files using a regular editor. Currently this filesystem is unmaintained. See for more info.
This one seems similar to WikipediaFS, but aimed at Plan9 and inferno. See for more info.
There are many benchmarks online about Linux flash filesystems. But most of them are outdated, where flash memory sizes are smaller than these days and the benchmarks miss recent developments such as LogFS and ubifs. Michael Opdenacker from has benchmarked flash filesystems in late 2008 and presented the results at Embedded Linux Conference Europe 2008. and are available.
