The mini_fo filesystem

 http://www.denx.de/wiki/bin/view/Know/MiniFOHome

 

http://www.denx.de/wiki/bin/view/Know/MiniFOFAQ

 

 

The mini_fo filesystem

[Posted May 10, 2005 by corbet]

 

Markus Klotzbuecher recently  announced the release of mini_fo 0.6.0. Mini_fo provides (what has been called in other systems) a "translucent" or "copy on write" filesystem. A read-only, base filesystem (possibly from a remote system or CDROM) can be made to appear, via mini_fo, as a local, writable filesystem. This functionality is useful for sharing filesystems with local overrides, live CD systems, sandboxing applications, and more.

At its core, mini_fo performs a simple fan-out operation. Each inode, dentry, and file structure associated with a mini_fo filesystem contains (via its private data) pointers to two other structures of the same type. One of them refers to the file or directory on the base filesystem; the other, instead, is for a local version of the file or directory on a local "storage filesystem." Both are hidden from user space, which thinks it is dealing directly with a file stored in the mini_fo filesystem.

When a mini_fo filesystem is first created, it appears as an exact copy of the underlying base filesystem. Any operation which reads files or directories is simply passed through to the base filesystem, with almost no additional overhead. In this mode, mini_fo functions as a sort of loopback filesystem.

Things change, however, when a file is opened for writing. In this case, mini_fo will create a copy of the file on the storage filesystem, with all of the data moved over. Any subsequent operations on that file will used the locally-stored version rather than the base version. So any changes made will appear locally, but they will not be propagated back to the base. Changes will be persistent across mounts as long as the storage directory used by mini_fo is not modified by anything except mini_fo.

Modified files are not the full story, of course; mini_fo must also cope with operations like deletes and renames. To that end, it maintains a set of lists of files which it knows about locally; there is one list for modified files, one for deleted files, one for files created locally, etc. These lists are stored in-kernel as standard linked lists. They are also written to the storage filesystem in a magic file (named META_dAfFgHE39ktF3HD2sr, for what it's worth) and reloaded from that file when the filesystem is mounted.

This release of mini_fo works with both the 2.4 and 2.6 kernels. Its author claims that it is intended for use with embedded systems, and thus has a small memory footprint. See the mini_fo web page for more information.

 

 

 

This is the mini_fo FAQ. Please feel free to post problems and solutions!

 

• How do I mount mini_fo?
• Why does mini_fo create these weird "META_dAfFgHE39ktF3HD2sr" in my storage directory?
• How can I overlay the root file system?
• But how can I really overlay the root file system (for the whole system)?
• After overlaying the root file system /proc, /sys, /dev or any file system mounted on the old root disappears!
• I get "permission denied" messages when trying to modify files via mini_fo, although ls -l shows sufficient privileges!

 

How do I mount mini_fo?

The syntax is:

 

mount -t mini_fo -o base=<base directory>,sto=<storage directory> <base directory> <mount point> 

yes, it is silly to have to specify the base directory twice, I hope to fix this soon.

See below for some examples.

 

---

 

Why does mini_fo create these weird "META_dAfFgHE39ktF3HD2sr" in my storage directory?

These files contain the meta data, that is used to keep track of modifications to the base file system. You can easily change this name by editing the "#define META_FILENAME" statement in mini_fo.h to whatever you prefer.

---

 

How can I overlay the root file system?

Mount mini_fo on top of the root file system:

# mount -t mini_fo -o base=/,sto=/tmp/sto/root / /mnt/mini_fo

Now change your root file system to the mini_fo mount point:

# chroot /mnt/mini_fo

Now you've got a shell with a mini_fo overlayed root file system.

---

But how can I really overlay the root file system (for the whole system)?

Ok, above wasn't the whole truth, as previously started processes and daemons stay with the old root file system. To do this properly, I guess you would have to overlay the root file system before init is started, and then start init after changing root. Has anybody tried this?

Well, I did it! Just created a script /etc/bootinit with something like this:

   insmod /lib/modules/mini_fo.o
   mount -t tmpfs none /tmp
   mkdir /tmp/sto
   mount -t mini_fo -o base=/,sto=/tmp/sto / /rw
   cd /rw
   mkdir old_rootfs

   pivot_root . old_rootfs
   exec /usr/sbin/chroot . /sbin/init

   echo "Oops, exec chroot didnt work! :( :( :( "
   exit 1

then included  init=/etc/bootinit in the kernel boot parameters line. It worked like a charm (never saw the Oops message, though :o) --  RicardoScop - 30 Jun 2005

 

---

After overlaying the root file system /proc, /sys, /dev or any file system mounted on the old root disappears!

This is normal behaviour. mini_fo only overlays the file system that was specified as base. It can't "detect" other file systems that are mounted somewhere on the base, so these mountpoints will be empty.

The solution is to simply mount file systems you want to overlay to their appropriate mount points in the overlaid root file system before chroot'ing. For above example (assuming the file system mounted on /home is a seperate partition):

# mount -t mini_fo -o base=/,sto=/tmp/sto/root / /mnt/mini_fo

# mount -t mini_fo -o base=/home/,sto=/tmp/sto/home/ /home/ /mnt/mini_fo/home/

# mount -t sysfs sys /mnt/mini_fo/sys/

# chroot /mnt/mini_fo

Note that sysfs is mounted directly. I don't think it would make much sense overlaying such a file system with mini_fo.

---

I get "permission denied" messages when trying to modify files via mini_fo, although ls -l shows sufficient privileges!

This is usually caused by insufficient privileges in the storage filesystem. Check that the user accessing the overlaid file system has privileges to modify the storage directory.

---

--  MarkusKlotzbuecher - 07 Jun 2005