Seite 2: Feintuning bei den Dateisystemen

Inhaltsverzeichnis

Neben dem Remapping-Thema gab es eher kleinere Änderungen im Dateisystembereich. btrfs spendiert der neue Kernel die Unterstützung für Zoned-Block-Devices. Obwohl das Ganze noch ziemlich "work in progess" ist, ist es schon jetzt im Mainline-Kernel gelandet.

In Flash-Dateisystem FS2FS ("Flash-Friendly File System") lässt sich im neuen Kernel neben dem Kompressionsalgorithmus nun auch der Grad der Kompression angeben. Dadurch lässt sich das Dateisystem besser an den Anwendungsbereich anzupassen. Zudem ist jetzt ein Modus für "LZ4 high compression" mit von der Partie.

Der NFS-Client kann im neuen Kernel mit "eager writes" zu schreibende Daten sofort übers Netzwerk an den Server schicken, statt sie erst m Page-Cache zwischenzuspeichern. Das reduziert den Speicherbedarf fürs Caching auf dem Client und soll in einigen Szenarien den Datendurchsatz steigern. Zudem erlaubt es sofortige Rückmeldung, wenn das Volume vollläuft.

Unabhängiger kcmp()-Call...

Mit Linux 5.12 ist der System-Call kcmp() unabhängig von der Software CRIU (Checkpoint/Restore in User Space) konfigurier- und nutzbar. Nach einigen Diskussionen in der Entwicklergemeinde durfte sich das Feature nun doch – trotz einiger Sicherheitsbedenken – vom ursprünglichen Einsatzszenario abnabeln.

Die CRIU-Software, mit der kcmp() 2012 ursprünglich eingeführt wurde, kann laufende Container einfrieren und ihren aktuellen Status (Checkpoint) auf einem Datenträger sichern. Dieser Checkpoint lässt sich – auch auf einem anderen Host – später in den Speicher zurückholen (Restore) und der Prozess wiederbeleben. Verwendet wird das unter anderem von Virtualisierungslösungen wie OpenVZ, LXC/LXD, Docker oder Padman.

Beim Restore eines Checkpoints sind alle Prozesse und verwendeten Ressourcen wieder so herzustellen, dass der Container später problemlos seine Arbeit wiederaufnehmen kann. Eine von zahlreichen Herausforderungen bei diesem Vorgang ist es, herauszufinden, ob womöglich zwei Dateideskriptoren, also eindeutige Kennungen, auf ein und dieselbe offene Datei im Kernel verweisen. Besonders kniffelig wird das, wenn die Deskriptoren in unterschiedlichen Prozessen beziehungsweise Threads beheimatet sind.

kcmp() löst dieses Problem: Der Aufruf kann beim Erzeugen eines Checkpoints prüfen, ob zwei Deskriptoren identisch sind. Dadurch lassen sich Fehlverhalten und Abstürze vermeiden, die aus einem Restore resultieren würden, bei dem aus einem einzigen, jedoch mehrfach referenzierten Dateideskriptor kurzerhand mehrere Deskriptoren gemacht würden.

...mit sicherheitsbedingten Einschränkungen

Mittlerweile wird die Funktionalität von kcmp() auch von Anwendungen genutzt, die keinen direkten Bezug zu Checkpoint/Restore haben. So fußt etwa Mesas os_same_file_description() auf kcmp(). Der Funktionsaufruf dient dazu, festzustellen, ob zwei Deskriptoren, beispielsweise ein Gerät und das Framework DMABUF, auf dieselbe Datei verweisen. Auch systemd nutzt kcmp(), nämlich um Duplikate im File Descriptor Store Service-bezogen aufzulösen.

Bislang war kcmp () nur dann, wenn der Kernel mit Support für Checkpoint/Restore konfiguriert wurde; andernfalls fehlte das Feature schlicht. Aus den – insbesondere im Fall von Mesa starken – Abhängigkeiten von kcmp () ergab sich letztlich jedoch die Notwendigkeit des Loslösens aus dem CheckPoint/Restore-Kontext. Daher landete der kcmp()-Patch aus Linux 5.12 bereits vor dessen Release nicht nur als Backport im LTS-Kernel 5.10.20, sondern wurde zudem auch in den Mainline-Kernel 5.11.3 zurück portiert.

Der Einsatz von kcmp() unterliegt allerdings Beschränkungen. Der aufrufende Prozess benötigt das Recht, ptrace() auf den Zielprozessen auszuführen; zudem müssen die involvierten Prozesse im gleichen PID-Namespace liegen. Dennoch sehen einige Kernel-Entwickler möglichen Exploits Tür und Tor geöffnet. Als Kompromiss ist kcmp() auch in 5.12 nicht per se, sondern nur dann aktiviert, wenn bestimmte Features wie Grafik (oder eben Checkpoint/Restore) ebenfalls aktiv sind.

Das jeweilige Auswahlkriterium lässt sich am einfachsten in der Hilfefunktion in "make menuconfig" unter "General setup -> Enable kcmp() system call" anzeigen. Im Menuconfig lässt sich kcmp() nicht losgelöst von diesen Kriterien aktivieren. Wer es dennoch testen will, kann mit dem Config-Makro CONFIG_KCMP in .config händisch experimentieren.