Getting Started Boot from ROM File System Selection

When building an embedded system, one of the important decisions which has to be made is which file systems to use. Linux provides a number of file systems, some of which are more suitable to embedded products than others.

Things which will influence the decision include:

• Does the file system need to be writable?
• Does the file system need to be writable in situ?
• Is performance paramount, or can you accept slightly lower performance for smaller code side or better media utilisation?

Options

Disk oriented file systems

Although only a minority of embedded systems have a rotating disk, these are the normal file systems which people will be familiar with from desktop systems, and so provide a useful comparison point.

• ext2 is the traditional file system on desktop and server Linux systems. It is fast, full featured, and makes good use of disk space, but is fairly large code. However for an embedded system it has one major failing. If power is removed without first unmounting the file system, it can result in disk corruption, so the next time the system starts it needs to perform a disk check, which can take a long time on a big disk.
• Increasingly Linux systems are using journaling file systems. These have a number of advantages, in particular they should provide higher throughput and avoid the need for a long consistency check when the system boots. The two most popular journaling file systems for Linux are ext3 and Reiser FS. However these two systems add even more code to the kernel image.
• Although not common, the minix file system has a number of advantages. It makes good use of disk space, at the expense of not providing some seldom used features, and is a reasonably small code footprint. However it does require a file system consistency check on reboot.

Memory oriented file system

In embedded systems, it is common to present a file system interface to an area of memory. Linux provides several ways to do this. The most common is to turn an area of memory into a block device, and then mount a normal file system (for example ext2) on top of the block device. This is done be enabling `RAM disk support' (CONFIG_BLK_DEV_RAM), and specifying the default size of each RAM disk. This has the added feature that the RAM disk contents can be initialised from a compressed file system image when the system boots. To do this enable `Initial RAM disk (initrd) support' (CONFIG_BLK_DEV_INITRD) and pass some additional parameters to the kernel to tell it where the image is in memory.

Although it is normal to use ext2 or minix file systems on a RAM disk, if the file system doesn't need to be writable, it can be more efficient to use the `Compressed ROM file system' (CONFIG_CRAMFS). By being read-only, and applying some restrictions to the file size and file system size, CramFS uses very little extra memory for file meta data. It is also able to effectively compress the data saving even more space.

Another way to hold a file system completely in memory is to use tmpfs (select `Virtual memory file system support' (CONFIG_TMPFS)). This has the advantage that the file system will shrink and expand to contain the contents, whereas a RAM disk size must be decided when the disk is created, and the full memory contents are allocated at that point.

Flash File Systems

Flash memory is common in embedded systems to allow field upgrades. However it can also be used to store a file system, albeit with some restrictions. Flash devices are characterised by being fairly fast to write to, but data cannot be overwritten without first being erased, and most devices only allow erasing of quite large blocks, which can take a long time.

The easiest way to use Flash as a file system is to use it to store a file system image, which can be accessed directly (using the MTD pseudo block device) or copied to a RAM disk. This disadvantage of this is that the file system is either read-only (for the first version) or read/write but volatile (for the RAM disk version). In many cases this is adequate, and does have some advantages (if the file system is corrupted for whatever reason, reset the system, and it is back to its previous state). However if the file system needs to be updated in place, then some other techniques can be used.

The most common way to put a writable file system into Flash in a modern Linux system is to use the Journaling Flash File System JFFS2. This uses journaling techniques similar to those used by high performance file systems such as ext3, but for very different reasons. As journaling appends all changes to a file system log, it doesn't need to update data in place, which is ideal for Flash. JFFS2 is also able to compress the data, making very effective use of available space. For more details on JFFS2 see the projects home page.

Instead of being built on top of the standard block device interface, JFFS2 uses the MTD Flash interface. This gives it visibility of the Flash characteristics, allowing more intelligent support of Flash devices, for example by being able to write at a finer granularity than the full `block', and by performing `wear leveling', thus improving performance when writing to the Flash and extending its life.

The main disadvantages of using JFFS2 are timing related. At boot time it has to scan the Flash building up tables of its state, which can take some time. Also periodically it does need to erase Flash sectors, which can take several seconds, during which time file system access is denied. However this can usually be overcome by using a buffer process or thread, which is decoupled from the real-time parts of the system.

We should also mention the Flash Translation Layer (FTL). This is a technique for mapping a normal block oriented file system onto Flash devices. At first glance this looks very useful. However it doesn't provide wear leveling, and because it only presents the normal block device interface, ends up doing more erase cycles trying to emulate the behavior of a magnetic disk. In addition there are problems with patents in some countries. For historical reasons we provide a brief description or how to use it. However in practice there is little to recommend FTL over JFFS2 these days.

Mix and match

As we have discussed, there are a large number of options for file systems, all of which have advantages and disadvantages. However, because it is possible to mount multiple file systems anywhere in the file hierarchy, it is possible to construct a custom file system which meets your requirements.

A typical example would be a system which has no need for a writable file system, except for some configuration files which need to be updated and non-volatile, and some temporary data which can be regenerated each time the system boots. In this case the root file system could be a CramFs file system (compressed and read-only), with a small JFFS2 file system mounted on /etc/config for the configuration files and a TmpFs file system mounted on /tmp for the temporary data files.

Alternative mechanisms exist to overcome some problems seen when booting. For example, maybe a kernel module is needed to access the main file system, which has to be mounted on /, but this module has to be loaded from a file system. This appears to be an insoluble problem, but a small utility called pivot_root comes to the rescue. Using this is the root file system is initially a small CramFs file system on an initialised RAM disk. When the start up scripts have finished loading the kernel module, pivot_root is invoked to swap in the main file system as the new root file system, and still give access to the small cramfs file system if required.