Kernel-Log – Was 3.9 bringt (1): Dateisysteme und Storage

Der Linux-Kernel kann SSDs nun als Festplatten-Cache konfigurieren. Btrfs unterstützt RAID 5 und 6 jetzt direkt im Dateisystem. Die Kernel-Entwickler haben zudem zwei Performance-Probleme beseitigt.

In Pocket speichern vorlesen Druckansicht 31 Kommentare lesen
Lesezeit: 12 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Am vergangenen Sonntag hat Linus Torvalds die vierte Vorabversion des Linux-Kernels 3.9 freigegeben. Er merkte dabei an, die Entwicklung sei bislang nicht zur Ruhe gekommen, und rief zum Testen des RCs auf.

Alle größeren Neuerungen von Linux 3.9 haben Torvalds und seine Mitstreiter wie üblich bereits in den zwei Wochen nach Freigabe der Version 3.8 Mitte Februar in den Kernel integriert. Größere Änderungen in der jetzt laufenden Stabilisierungsphase von 3.9 sind selten, daher können wir bereits jetzt einen umfassenden Überblick über die wichtigsten Neuerungen geben, die die Ende April erwartete Linux-Version bringen wird.

Der Überblick erfolgt in einer Artikelserie, die nacheinander die verschiedenen Bereiche des Kernels behandelt. Den Anfang macht die folgende Beschreibung zu den Neuerungen rund um Datenträgertechniken und Dateisysteme. In den nächsten Wochen folgen Artikel zu Grafiktreibern, Kernel-Infrastruktur, Netzwerktechniken, Prozessor/Plattform-Unterstützung und Treibern für andere Hardware.

Der vom Logical Volume Manager (LVM) verwendete, aber auch unabhängig davon nutzbare Device Mapper enthält jetzt das Cache Target "dm-cache" (1, 2, 3). Mit ihm lässt sich ein Datenträger als Cache für einen anderen Datenträger einrichten – etwa eine SSD als Cache für eine Festplatte. Das kann das Schreiben von Daten beschleunigen, wenn die schnelle SSD die Daten annimmt und sie später in einem ruhigeren Moment auf die langsamere Festplatte schreibt. Das Cache-Target kann auch häufig von der Festplatte gelesene Daten auf der SSD bereithalten, um den Zugriff darauf zu beschleunigen. Wie das Caching-Target dabei vorgeht, ist nicht fest in Dm-Cache einprogrammiert, sondern wird durch "policy modules" geregelt. Details zur Arbeitsweise erläutert die Dokumentation zum Cache-Target und den bislang integrierten Policy-Modulen "multiqueue" und "cleaner".

Die als experimentell eingestufte Funktion ist eine Neuentwicklung, die mit einem anderen Ansatzpunkt im Kernel ähnliches leistet wie die älteren, aber unabhängig vom Kernel gewarteten Caching-Lösungen Flashcache und Bcache. Der Entwickler von Letzterer arbeitet seit einer Weile auf die Integration in den Kernel hin und hat in letzter Zeit einige dafür benötigte Grundlagen im Block-Layer von Linux geschaffen. Es schien vorübergehend unklar, ob die Kernel-Entwickler Bcache nach der Integration von Dm-Cache noch aufnehmen würden. Jens Axboe, der Betreuer des Block-I/O-Codes im Linux-Kernel, hat Bcache aber in seinen Git-Entwicklerzweig aufgenommen, in dem er die Änderungen sammelt, die er bei Linux 3.10 integrierten will. Um Flashcache ist es in letzter Zeit sehr ruhig geworden. Axboe hat sich aber vor der Integration von Dm-Cache dafür ausgesprochen, dass die Flashcache-Weiterentwicklung EnhanceIO SSD Caching Software in den Staging-Bereich des Kernel eingehen sollte; dieser Code stammt von der Firma Stec, die auf Hard- und Software rund um SSDs spezialisiert ist.

Das Btrfs-Dateisystem beherrscht nun neben den RAID-Leveln 0 und 1 die Anfang Februar vorgestellte und als experimentell eingestufte Unterstützung für RAID 5 und 6. RAID-Fähigkeiten direkt im Dateisystem zu implementieren ermöglicht Funktionen, die nur umständlich mit dem klassischen Schichtmodell zu realisieren sind, wo das Dateisystem das RAID wie einen großen Datenträger anspricht, ohne etwas über seine Interna zu wissen.

Durch die RAID-Funktionen braucht Btrfs beispielsweise nach dem Ausfall und dem Austausch eines Datenträgers im Btrfs-RAIDs nur die belegten Bereiche zu restaurieren, weil Btrfs diese anhand der Dateisysteminformationen erkennen kann; ein mit Mdadm administriertes Linux-Software-RAID kommt durch die Abstraktion an diese Informationen nicht ran und muss daher das komplette RAID-Volume restaurieren, was länger dauert.

Auch bei Datenfehlern bietet ein Dateisystem-internes RAID Vorteile, da das Dateisystem direkt mit den Datenträgern sprechen kann, aus denen sich der Verbund zusammensetzt; mit Hilfe der im Dateisystem hinterlegten Prüfsummen kann Btrfs daher bei einem RAID 1 im Idealfall erkennen, welcher Datenträger eines Verbunds richtige oder falsche Daten liefert. Btrfs kann zudem in einem Dateisystem unterschiedliche RAID-Techniken kombinieren; etwa Metadaten mit RAID-1-Techniken (Mirroring) ablegen, während es für die Nutzdaten RAID-0-Funktionen (Striping) nutzt.

Die Entwickler des weiterhin experimentellen Dateisystems haben noch eine Reihe weiterer Änderungen vorgenommen. Einige von ihnen sollen die als problematisch geltende Fsync-Performance von Btrfs weiter verbessern (u. a. 1). Beim Defragmentieren von Btrfs-Dateisystemen mit Snapshots bleiben von mehreren Snapshots verwendete Datenbereiche nun erhalten und werden nicht mehr aufgespalten, was Speicherplatz verschwendet hat. Ein Suse-Entwickler hat zudem Send/Receive-Code verbessert, damit der auf Wunsch nur noch Metadaten sendet; das soll Suses "snapper" effizienter machen.

Die Ext-Dateisystementwickler haben unter anderem ein bei Linux 3.0 entstandenes Performance-Problem im von Ext4 verwendeten Journaling-Layer JBD2 behoben.

CIFS, NFS und eine Reihe weiterer Dateisysteme erhielten Unterstützung für User Namespaces. XFS wurde aber noch nicht angepasst, daher lassen sich User Namespaces bei der Kernel-Konfiguration weiterhin nur aktivieren, wenn man XFS deaktiviert; viele Distributionen dürften den Support für User Namespaces in ihren Kerneln daher weiter außen vor lassen.

Unter den Änderungen an Fuse sind Optimierungen für Scatter-Gather Direct IO und Unterstützung für das Readdirplus-API; das wird auch schon bei NFS eingesetzt und kann bestimmte Datei-Operationen beschleunigen.

Mit /sys/fs/pstore/ gibt es im Sysfs-Dateisystem nun ein Verzeichnis zum Einhängen des Pstore-Dateisystems. Darüber lassen sich beim einem Systemabsturz Daten ablegen, um die Absturzursache nach dem Neustart zu analysieren.

Der Cgroup-Controller zum Regulieren der Lese- und Schreibraten von Datenträgern unterstützt jetzt hierarchische Kontrollgruppen korrekt, wenn CFQ als I/O-Scheduler genutzt wird; das gilt allerdings noch nicht für das Throttling von I/O (u. a. 1, 2).

Änderungen am Memory Management des Kernel können die Latenzen reduzieren, die durch "Stable Pages" entstehen (u. a. 1). Seit Linux 3.0 schützen sie die bereits beim Kernel zum Schreiben abgelieferten, aber noch nicht geschriebenen Daten vor weiteren Modifikationen, was unter anderem bei der Prüfsummenberechnung und der Kompression durch das Dateisystem wichtig ist. Details erläutert ein LWN.net-Artikel.

Die Libata-Treiber unterstützten nun Zero-Power Optical Device Drives (ZPODD) – optische Laufwerke, die das System zu Stromsparzwecken nahezu komplett ausschalten kann, wenn keine beispielsweise keine DVD im Laufwerk liegt (u. a. 1, 2).