Whenever it is a requirement to be able to switch off an embedded device without any previous preparation, the next question is about the consistence of the used filesystem. If this filesystem is used to be written with new content and this new/changed data hasn't done it's way to the persistent media when the power is cut, this new/changed data is lost.

On the following system start most of the time the filesystem itself can be repaired and be consistent again, but the new/changed data from the last run is still lost. And sometimes it even happens not only the data the filesystem manages is inconsistent, its own management information can be broken as well. If this happens, the whole filesystem is broken and the system stops working. There are many filesystems out which tries to deal with such failures in any circumstances. But from time to time we even see a loss, where every last resort seems to fail.

One way out of this dilemma is the use of the filesystem in a read-only manner. Its content will be completely defined at build-time and does not need any further change at run-time - it is fully static.

But there are many applications and tools which still expect to be able to write to the filesystem hierarchy, maybe simply for their logging information. In most cases this is valid at least for the filesystem hierarchy below /var.

Until now PTXdist used a very simple approach as a solution: at run-time it locates three RAM disks in /var/lock, /var/log and /var/tmp to provide write support at these specific locations. Even if this approach is simple and very optimistic, it yet worked for surprisingly many use cases.

One essential assumption for this approach is, the data written to these locations must not be persistent across reboots.

But more and more applications and tools have new requirements to the filesystem hierarchy below /var and the approach used until now is ways to inflexible and thus isn't able to solve the issue anymore.

For this reason the PTXdist July release provides an additional (configurable) approach to have the filesystem hierarchy below var writable: "overlay filesystem". This is a Linux kernel filesystem which supports to overlay a static filesystem by a different writable filesystem.

The most simple overlaying writable filesystem is a RAM disk and it is from the beginning initially empty. In this case read accesses provides the content from the underlying static filesystem. That means after the system comes up, the content is always in an initial state. If data gets written to this filesystem hierarchy it is stored in the writable filesystem instead. The next read access to it will then be served by the writable filesystem instead and no longer by the underlying static filesystem.

Making use of this new PTXdist feature is very simple: one requirement is the overlay filesystem feature from the Linux kernel at run-time. It must be enabled first (CONFIG_OVERLAY_FS=y). Additionally in the PTXdist configuration menu the "overlay /var with RAM disk" must be enabled (symbol ROOTFS_VAR_OVERLAYFS=y). After that, the root filesystem image must be created and used at the target system.

At run-time this new configuration can be checked by running the "mount" command:

$ mount
[...]
/dev/root on / type ext4 (ro,relatime,errors=remount-ro)
[...]
overlay on /var type overlay
(rw,relatime,lowerdir=/var,upperdir=/run/varoverlayfs/upper,workdir=/run/varoverlayfs/work)
[...]

The root filesystem is mounted "ro" ("read-only") and the "overlay filesystem" is mounted on top of the /var directory.

It is now possible to make use of commands likes "mkdir" and "touch" in a usual manner in all directories below the /var hierarchy.

Detail: by the way the used RAM disk isn't part of the mount's command output. After mounting it with the "overly filesystem" it will unmounted again immediately and intentionally. Due to this it is invisible, but still existent and used by the "overlay filesystem". When the "overlay filesystem" gets unmounted, this invisible RAM disk gets freed as well.