Wann immer es erforderlich ist, ein embedded Gerät einfach so ohne Vorbereitung ausschalten zu können, kommt das Thema Dateisystem-Konsistenz auf. Werden Daten geschrieben und haben vor dem Ausschalten ihren Weg auf das Speichermedium noch nicht vollständig gefunden, droht deren Verlust.

Beim nächsten Systemstart kann das Dateisystem an sich in den meisten Fällen wieder in einen konsistenten Zustand gebracht werden. Die beim letzten Lauf geänderten Daten sind aber praktisch immer verloren. Und manchmal passiert es eben auch, dass nicht nur die Daten im Dateisystem inkonsistent sind, sondern mitunter auch seine Verwaltungsstrukturen. Dann ist das gesamte Dateisystem unbrauchbar und in dessen Folge das gesamte System nicht mehr benutzbar. Diverse Dateisysteme verfügen über Mechanismen, die die Konsistenz unter allen Umständen sicherstellen sollen. Aber auch hier sehen wir immer wieder Ausfälle im Feld, wo diese Mechanismen aus den verschiedensten Gründen doch versagen.

Eine Lösung für dieses Dilemma ist, ein Dateisystem im reinen Lesebetrieb zu verwenden ("read-only"). Das Dateisystem wird beim Bauen vollständig definiert und braucht zur Laufzeit keine Änderung mehr - ist also vollständig statisch.

Allerdings funktionieren dann nicht mehr alle Applikationen und Werkzeuge, da sie an bestimmten Stellen in der Dateisystemhierarchie schreibenden Zugriff erfordern, und sei es nur, um ihre Logausgaben zu sichern. In den allermeisten Fällen betrifft das die Dateisystemhierarchie unter /var.

Bisher hat PTXdist den Ansatz verfolgt, in /var/lock, /var/log und /var/tmp drei RAM-Disks zu platzieren, die somit in genau diesen drei Unterverzeichnissen das Schreiben ermöglichen. Auch wenn dieser Ansatz einfach und auch sehr optimistisch ist, hat er bisher erstaunlich gut funktioniert.

Eine wesentliche Annahme bei diesem Ansatz ist, dass die geschriebenen Daten einen Systemneustart nicht "überleben", also nicht dauerhaft gespeichert werden müssen.

Aber mehr und mehr Applikationen und Werkzeuge haben neue Anforderungen an die Dateisystemhierarchie unter /var, und somit ist der bisherige Ansatz zu unflexibel geworden und funktioniert daher häufig nicht mehr.

Aus diesem Grund gibt es nun mit dem PTXdist-Juli-Release einen weiteren (konfigurierbaren) Ansatz, die Dateisystemhierarchie unter /var beschreibbar zu machen: "Overlay Filesystem". Dieses vom Linux-Kernel unterstützte Dateisystem ermöglicht es, ein statisches Dateisystem durch ein änderbares Dateisystem zu überlagern.

Im einfachsten Fall ist das änderbare Dateisystem eine RAM-Disk und beim Systemstart zunächst leer. Dann liefern lesende Zugriffe zunächst den Inhalt des darunterliegenden statischen Dateisystems. Somit gilt also nach einem Systemstart immer ein initialer Zustand. Werden Daten geschrieben, werden sie nur im änderbaren Dateisystem gespeichert. Ein wiederholter lesender Zugriff auf diese Daten wird danach aus dem änderbaren Dateisystem bedient, nicht mehr aus dem darunter liegenden statischen Dateisystem.

Die Nutzung dieses neuen Ansatzes in PTXdist ist denkbar einfach. Voraussetzung ist, dass der eingesetzte Linux-Kernel das "Overlay Filesystem" (Symbol CONFIG_OVERLAY_FS=y) unterstützt. Weiterhin muss im PTXdist-Konfigurationsmenü "overlay /var with RAM disk" aktiviert werden (Symbol ROOTFS_VAR_OVERLAYFS=y). Danach reicht es, das Root-Dateisystem neu erstellen zu lassen und zu benutzen.

Zur Laufzeit kann mittels "mount"-Kommando geprüft werden, ob die neue Konfiguration wirksam ist:

$ 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)
[...]

Das Root-Dateisystem ist "ro" ("read-only") eingehängt und das "overlay filesystem" auf /var.

Kommandos wie "mkdir" oder "touch" können nun gewohnt auf alle Bereiche in /var angewendet werden.

Detail: Die dabei verwendete RAM-Disk ist in der Ausgabe des "mount"-Kommandos übrigens nicht sichtbar. Sie wird nach dem Einhängen des "overlay filesystem" wieder "offiziell" ausgehängt. Da sie aber benutzt wird, bleibt sie unsichtbar bestehen. Sobald das sie nutzende "overlay filesystem" ausgehängt wird, wird sie ebenfalls ausgehängt und die von ihr belegten Speicherressourcen frei gegeben.