Container basieren auf einem einfachen, aber sehr wirkungsvollen Dateisystemmodell: Ein Image besteht aus mehreren unveränderlichen Layern, die beim Start eines Containers „übereinandergeschichtet“ werden. Oben drauf kommt ein beschreibbarer Layer, der alle Änderungen aufnimmt – temporär und isoliert. Dieses Prinzip erlaubt schnelle Starts, geringe Speicherduplizierung und klare Trennung von Image und Laufzeit.
Das Herzstück dieser Mechanik ist das Overlay-Dateisystem. Bei Podman kommen zwei Varianten zum Einsatz: das klassische, kernelbasierte OverlayFS und die userspace-basierte Variante fuse-overlayfs.
Beide erfüllen denselben Zweck, aber unter sehr unterschiedlichen Voraussetzungen.
OverlayFS ist seit vielen Jahren fester Bestandteil des Linux-Kernels. Es erlaubt, zwei Verzeichnisse – ein „lowerdir“ (read-only) und ein „upperdir“ (read-write) – zu einem einzigen zusammenzuführen. Container-Layer werden so übereinandergelegt, dass der Nutzer eine konsolidierte Sicht erhält, ohne dass Dateien kopiert werden müssen.
OverlayFS arbeitet im Kernelmodus. Das bedeutet:
Ein vereinfachtes Schichtmodell:
OverlayFS ist in nahezu allen produktiven Containerumgebungen der Standard, solange root-Rechte zur Verfügung stehen.
OverlayFS im Kernel setzt root voraus. Das Dateisystem führt Operationen durch, die privilegiert sind: Änderungen in Whiteout-Dateien, Vererbungslogik, Metadatenmanipulationen. Rootless-Podman kann diese Operationen naturgemäß nicht durchführen.
Genau hier schlägt die Stunde von fuse-overlayfs.
Fuse-basierte Dateisysteme verschieben die Logik vom Kernel in den Userspace. Das mag zunächst wie ein Rückschritt wirken, doch für Rootless-Umgebungen ist es der Schlüssel zur Funktionsfähigkeit.
fuse-overlayfs ermöglicht:
Der Hauptunterschied liegt in der Ausführungsschicht: Hier führt nicht der Kernel die Overlay-Operationen durch, sondern ein Userspace-Prozess.
Eine Skizze:
Dadurch sind Rootless-Container praktisch überhaupt erst möglich.
OverlayFS ist schneller und effizienter. fuse-overlayfs ist flexibler, aber kostspieliger:
Für Build-Pipelines, die zehntausende kleine Dateien erzeugen (z. B. bei Installationsvorgängen), kann das Performanceprofil deutlich spürbar sein.
Ein praktischer Tipp: buildah unshare verlagert
Buildschritte in einen User Namespace und verbessert damit manche
Abläufe im Rootless-Modus.
Sowohl OverlayFS als auch fuse-overlayfs implementieren Whiteouts – kleine Markerdateien, die anzeigen, dass eine Datei in einem unteren Layer gelöscht wurde. Diese Mechanik ist essenziell, um Container wie echte Dateisysteme wirken zu lassen.
Beispiel:
Das geschieht über .wh.<filename> im oberen
Layer.
Diese Details erklären viele Effekte, die beim Überschreiben oder Aktualisieren großer Dateien innerhalb eines Containerlayers auftreten.
Host-Mounts (Bind Mounts) umgehen OverlayFS teilweise oder vollständig – und damit auch dessen Semantik. Besonders im Rootless-Modus treten Effekte auf wie:
Podman bietet hierfür Mappingmechanismen über Mount-Optionen wie
:U, die Host-UIDs und Container-UIDs automatisch
verschieben.
Eine grobe Orientierung:
OverlayFS (Kernel) ideal für produktive Deployments, hohe I/O-Leistung, große Datenmengen
fuse-overlayfs (Userspace) ideal für rootlosen Betrieb, Workstations, Entwicklungsumgebungen, Multi-User-Maschinen
Bind Mounts ideal für große Daten oder Artefakte, sofern Eigentümer- und Rechteprobleme berücksichtigt werden
Beide Backends sind funktional ähnlich; der Unterschied liegt im Kontext: Rootful versus rootless, Performance versus Flexibilität.
OverlayFS und fuse-overlayfs bestimmen maßgeblich das Verhalten von Containern: Startzeiten, Dateirechte, Build-Geschwindigkeit, I/O-Last und Debugging-Verhalten. In Podman ist das Storage-Backend keine Randnotiz, sondern eine zentrale Säule des Systems.