Kernel-Log – Was 3.13 bringt (1): Dateisysteme und Storage
Der Kernel ist jetzt erheblich besser für besonders flotte Datenträger gerüstet. Vor Btrfs wird nicht mehr so deutlich gewarnt. Das von vielen Live-CDs verwendete Squashfs soll erheblich schneller arbeiten.
- Thorsten Leemhuis
Zum Ende der vergangenen Arbeitswoche hat Linus Torvalds die dritte Vorabversion von Linux 3.13 veröffentlicht. Größere Neuerungen bringt sie nicht, denn die Hauptentwicklungsphase dieser Version endete bereits in der zweiten Novemberhälfte, als Linux 3.12 knapp drei Wochen alt war. Das Kernel-Log kann daher schon jetzt einen umfassenden Überblick über die wichtigsten Neuerungen geben, die der in etwa vier Wochen erwartete Kernel bringt. Den Anfang macht die folgende Beschreibung zu den Neuerungen rund um Dateisysteme und Storage-Hardware; in den nächsten Wochen folgen Artikel zu Grafiktreibern, Netzwerk-Unterstützung, Kernel-Infrastruktur, Prozessor/Plattform-Unterstützung und Treibern für andere Hardware.
Moderneres Storage-Interface
Der in Kernel 3.13 integrierte Multi-Queue Block IO Queueing Mechanism verspricht Linux für besonders schnelle Datenträger fit zu machen – also PCIe-SSDs, NVMe-Hardware und andere Datenträger, die noch mehr IO-Operationen pro Sekunde (IOPS) ausführen können als aktuelle Desktop- und Notebook-SSDs. Dazu stellt das kurz "blk-mq" genannte Framework den Storage-Treibern unter anderem Grundfunktionen zur Verfügung, die die Arbeit auf mehrere Warteschlangen verteilen; anders als bei den Block-Layer-Funktionen, auf die Storage-Treiber bislang zurückgreifen, verteilen sich die Aufgaben so erheblich besser auf die verfügbaren CPU-Kerne. Nur so lässt sich das Potenzial der heute schnellsten Datenträger nutzen, daher haben einige Treiber für flotte Storage-Hardware bereits viele der vom Block Layer gebotenen Funktionen links liegen gelassen und alles selbst erledigt.
Laut Jens Axboe, der der Block Layer betreut und auch blk-mq maßgeblich vorangetrieben hat, sollen auch Treiber für nicht so rasend schnelle Datenträger von der neuen Multiqueue-Infrastruktur profitieren. Die nutzt allerdings bislang nur der schon länger im Kernel enthaltene Treiber virtio-blk, über den virtuelle Maschinen mit möglichst wenig Overhead die Datenträger des Wirts nutzen können; bei 3.14 wollen die Kernel-Entwickler weitere Treiber konvertieren.
Weitere Hintergründe zu blk-mq liefern der Commit-Kommentar, der Merge-Request und ein LWN.net-Artikel. Noch detailliertere Informationen enthält die Textfassung des Vortrags "Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems", an dem Axboe mitgearbeitet hat; das PDF nennt zahlreiche Messwerte, laut denen der neue Ansatz auf Multikern-Systemen nicht nur besser skaliert, sondern auch erheblich mehr Performance liefert.
Multi-Queue Block IO Queueing Mechanism in Linux 3.13 (3 Bilder)
Btrfs
Beim weiterhin experimentellen Dateisystem Btrfs gab es "wie gewohnt" einige Fehlerkorrekturen, Aufräumarbeiten und Performance-Verbesserungen, wie Chris Mason im Kommentar zum Haupt-Merge des Btrfs-Codes schreibt. Der leitende Btrfs-Entwickler, der kürzlich zusammen mit Btrfs-Hacker Josef Bacik von Fusion IO zu Facebook gewechselt ist, lieferte indes noch einen zweiten Schwung Änderungen hinterher, die eine Anpassung des bei der Kernel-Konfiguration eingeblendeten Hilfetextes zu Btrfs enthält. Dadurch verschwindet der in fetten Lettern geschriebene Hinweis, das On-Disk-Format des Dateisystems könne sich noch ändern. Stattdessen heißt es jetzt, das Datenträgerformat solle sich nur ändern, wenn es dafür gute Gründe gibt; wenn es solche gäbe, dann sollen auch neue Kernel Datenträger mit dem alten Format weiter unterstützen. So handhaben es etwa auch die Entwickler der Ext-Dateisysteme, bei denen es diesmal nur kleinere Änderungen gab.
Squashfs, CIFS, ...
Squashfs, das viele Linux-Distributionen zur Kompression des Root-Dateisystems ihrer Live-Medien nutzen, schreibt dekomprimierte Dateien jetzt direkt in den Page Cache; wie der Entwickler im Commit-Kommentar erläutert, konnte das den Durchsatz in einem Test von 13,7 auf 67,6 MByte/s steigern. Eine weitere Geschwindigkeitsverbesserung verspricht das Dekomprimieren mit mehreren Threads, was die Laufzeit eines Testszenarios mit vier Threads von 99 auf 9 Sekunden verkürzte (1, 2).
Beim CIFS-Dateisystem zum Zugriff auf Windows- und Samba-Server lässt sich jetzt das Kompressions-Dateiattribut abfragen und setzen (1, 2). CIFS unterstützt nun auch Server-side Copy Offload (1, 2, 3). Bei dieser in Samba 4.1 implementierten Technik müssen Daten, die ein Client von einer Stelle eines Servers an eine andere kopiert, nicht erst vom Server zum Client und anschließend wieder zurück übertragen werden.
FUSE, das Filesystem in Userspace, implementiert nun die Rücksprungfunktion Writepages; das verspricht das Schreiben via mmaped zu beschleunigen und ebnet den Weg zur Unterstützung von gepuffertem Writeback.
Bcache, Device Mapper, ...
Das SSD-Caching-Framework Bcache soll geringere Latenzen aufweisen, wenn die Garbage Collection zur Tat schreitet.
In der neuen "Passthrough"-Betriebsart führt das im Device Mapper angesiedelte SSD-Caching-Framework dm-cache alle Operationen ohne Cache aus; dadurch lässt sich ein Dm-Cache-Verbund schon verwenden, selbst wenn nach einem Absturz noch die Cache-Kohärenz geprüft werden muss.
Neben den Truecrypt-Containern mit LRW- oder XTS-Block-Verschlüsselung unterstützt der Device Mapper nun auch Container mit dem älteren Format CBC.
Zum Kernel stieß ein Treiber für die Stec PCIe-SSD S1120.
