OverlayFileSystems < DULG

-%SECTION0{name=OverlayFileSystems}% Overlay File Systems

---++ Introduction

Overlay File Systems provide an interesting approach to several frequent
problems in Embedded Systems.
For example,
==mini_fo== is a virtual kernel file system
that can make read-only file systems writable.
This is done by redirecting modifying operations
to a writeable location called "storage directory",
and leaving the original data in the "base directory" untouched.
When reading, the file system merges the modifed
and  original data so that only the newest versions will appear.
This occurs transparently to the user,
who can access the data like on any other read-write file system.

---++ What it is good for?

In embedded systems the main use of ==mini_fo==
is to overlay the root file system.
This means it is mounted on top of the regular root file system,
thereby allowing applications or users
to transparently make modifications to it
but redirecting these to a different location.

Some examples of why this is usefull are explained in the following sections.

---+++ Making a _read-only_ root filesystem _writeable_

Root file systems stored in flash are often read only,
such as [[DULG.RootFileSystemOnACramfsFileSystem][cramfs]]
or [[DULG.RootFileSystemOnAReadOnlyExt2FileSystem][read only ext2]].
While this offers major advantages in terms of speed and flash memory footprint,
it nevertheless is often desireable to be able to modify the root file system,
for example to 

   * apply (small) software updates
     without having to burn a whole new root file system image to flash
   * make modifications during developement
     when frequent changes to the root file system occur.

This can be achieved by mounting ==mini_fo==
on top of the root file system
and using a (probably small) writeable partition
as the storage file system.
This could be either a JFFS2 flash file system,
or during development even an external hard disk.
This has the following advantages:
   * read-only file systems
     (fast, small memory footprint)
     can be used like persistent writable file systems
     (in contrast to a ramdisk)
   * slow flash journalling file systems
     with large flash memory footprint can be avoided.

---+++ Non persistant changes

Ramdisks are often used
when the root file system needs to be modified non-persistantly.
This works well,
but downsides are the large RAM memory footprint
and the time costly operation of copying the ramdisk into RAM
during startup.
These can be avoided by overlaying the root file system
as in the previous example
but with the difference that the [[DULG.FilesystemTMPFS][tmpfs file system]]
is used as storage.
Thus _only_ modified files are stored in RAM,
and can even be swapped out if neccessary.
This saves boot time and RAM!

---+++ Resetable changes

==Mini_fo== can be easily used to implement a
"reset to factory defaults" function
by overlaying the default root file system.
When configuration changes are made,
these are automatically directed to the storage file system
and take precedence over the original files.
Now, to restore the system to factory defaults,
all that needs to be done is delete
the contents of the storage directory.
This will remove all changes made to the root file system
and return it to the original state.

%X% Note: Deleting the contents of the storage directory
should only be done when the overlay file system is unmounted.


---++ Examples

Generally,
there are two different ways of overlaying the root file system,
which both make sense in different scenarios.

---+++ Starting a single application in a chrooted overlayed environment

This is easy.
Let's assume "/" is the read-only root file system
and /dev/mtdblock5 contains a small JFFS2 flash partition
that shall be used to store modifications
made by application "/usr/bin/autoPilot":
<verbatim>
# mount -t jffs2 /dev/mtdblock5 /tmp/sto
# insmod mini_fo.o
# mount -t mini_fo -o base=/,sto=/tmp/sto/ / /mnt/mini_fo/
# cd /mnt/mini_fo/
# chroot . /usr/bin/autoPilot
</verbatim>
The ==mini_fo== file system is mounted with "/" as base directory,
"/tmp/sto/" as storage directory to the mount point "/mnt/mini_fo".
After that, =chroot(1)= is used to start the application
with the new file system root "/mnt/mini_fo".
All modifications made by the application
will be stored to the JFFS2 file system in /tmp/sto.

---+++ Starting the whole system system in chrooted overlayed environment

This is more interesting,
and a bit trickier,
as mounting needs to be done during system startup
_after_ the root file system has been mounted,
but _before_ init is started.
The best way to do this is to have a script
that mounts the mini_fo file system on top of root
and then starts init in the chrooted overlayed environment.
For example assume the following script "overlay_init", stored in /sbin/:
<verbatim>
#!/bin/bash
#
# mount mini_fo overlay file system and execute init
#

# make sure these exist in the read-only file system
STORAGE=/tmp/sto
MOUNT_POINT=/mnt/mini_fo/

# mount tmpfs as storage file system with a maximum size of 32MB
mount -t tmpfs -o rw,size=32M none $STORAGE

/sbin/modprobe mini_fo
mount -t mini_fo -o base=/,sto=$STORAGE / $MOUNT_POINT

exec /usr/sbin/chroot $MOUNT_POINT /sbin/init

echo "exec chroot failed, bad!"
exec /bin/sh

exit 1
</verbatim>

Now its easy to choose between a ==mini_fo== overlayed
and the regular non overlayed system
just by setting the "init" kernel parameter
in the boot loader to "init=/sbin/overlay_init".

---++ Tips
   * =pivot_root(1)= can be used with chroot
     if there is need to access the original non overlayed root file system
     from the chrooted overlayed environment.

---++ Performance overhead

The ==mini_fo== file system is inserted as an additional layer
between the VFS and the native file system,
and thus creates some overhead
that varies strongly
depending of the operation performed.

   1 modifying a regular file for the first time
     %BR%
     This results in a copy
     of the original file
     beeing created in the storage directory,
     that is then modified.
     Overhead depends on the size of the modified file.
   1 Reading from files,
     creating new files,
     modifying already modified files
     %BR%
     These operations are passed directly
     through to the lower native layer,
     and only impose an overhead of 1-2%.

---++ Further information

This section discusses how the ==mini_fo== overlay file system
can be used in embedded systems.
More general information is available at the
==mini_fo== project page:
[[Know.MiniFOHome][http://www.denx.de/wiki/Know/MiniFOHome]].
9.6. Root File System Selection		1. Abstract		9.8. The Persistent RAM File system (PRAMFS)
Prev		Home		Next