Kernel-Log – Was 3.2 bringt (2): Dateisysteme

Inhaltsverzeichnis

Kurz vor Thanksgiving hat Linus Torvalds vergangene Woche die dritte Vorabversion von Linux 3.2 veröffentlicht. Die Commits seit dem RC2 seien größtenteils klein und angemessen gewesen; es habe aber etwas mehr Änderungen gegeben als ihm lieb sei, sagte er zum RC3.

Ende dieser oder Anfang nächste Woche dürfte Torvalds die vierte Vorabversion der Anfang bis Mitte Januar anstehenden Linux-Version nachlegen. Das Kernel-Log nimmt die fortschreitende Entwicklung von Linux 3.2 zum Anlass, die Mini-Serie "Was 3.2 bringt" mit der Beschreibung der Neuerungen rund um Dateisysteme fortzusetzen. Den Anfang dieser Artikel-Reihe hat eine Übersicht der Änderungen an Netzwerk-Treibern und -Infrastruktur gemacht; in den kommenden Wochen werden Artikel zum architekturabhängigen Code, zur Kernel-Infrastruktur und zu Treibern für sonstige Hardware folgen.

Große Brocken

Das Ext4-Dateisystem bietet nun Unterstützung für "Big Allocation Blocks" (u. .a 1, 2, 3). Durch diese kurz Bigalloc genannten Technik bündelt Ext4 die zum Speichern von Daten verwendeten 4K-Blöcke zu bis zu 1 MByte großen Einheiten ("Cluster"). Das reduziert den Verwaltungs-Overhead beim Speichern großer Dateien und soll die Performance mancher Arbeitsszenarien deutlich steigern . Es wird aber auch verschwenderischer mit dem Speicherplatz umgegangen: jede Datei belegt mindestens einen ganzen Cluster. Bigalloc-Dateisysteme lassen sich mit der noch in Entwicklung befindlichen Version 1.42 der Ext-Werkzeugsammlung E2fsprogs verwenden; zum Anlegen dient wie gewohnt mkfs.ext4, dem man über den neuen Parameter "-C" die gewünschte Cluster-Größe mitteilt. [Update 20111130-0815] Kurz nach der Veröffentlichung dieses Kernels-Logs wurde die Version 1.42 der E2fsprogs freigegeben. [/Update]

Ext-Dateisystementwickler Theodore 'tytso' Ts'o hat zudem einen alten Algorithmus zum Allozieren von Speicherplatz entfernt (ext3, ext4). Durch einige weitere Änderungen soll Ext4 besser reagieren, wenn der Anwender nicht miteinander kombinierbare Mount-Optionen spezifiziert. Auf einem Vortrag im Rahmen der Linuxcon Europe 2011 hatte Theodore 'tytso' Ts'o kürzlich betont, Ext4 sei in "typischen Konfigurationen" (etwa Standard-Mount-Optionen mit und ohne Journal) stabil; bei Angabe und Kombination mancher Mount-Parameter – etwa jenen zum Speichern des Journals auf einem anderen Datenträger – seien aber Probleme möglich oder gar wahrscheinlich, da diese kaum getestet würden. Ausführliche Integritätstests seien bei den vielen Kombinationsmöglichkeiten praktisch nicht möglich, daher will er darauf hinarbeiten, die Zahl der Optionen zu reduzieren.

Die Folien seines Vortrags liegen bislang nicht auf der Webseite der Konferenz. Dort finden sich allerdings bereits PDF-Dokumente mit einigen Hintergründen zu jüngsten Entwicklungen bei Ext4 und Btrfs, die in den Vorträgen "The Ongoing Evolution of Ext4: New Features and Performance Enhancements" von Lukas Czerner und "Quo vadis Linux File Systems: An Operations Point of View on Ext4 and Btrfs" von Udo Seidel zur Sprache kamen.

Robuster

Das weiterhin experimentelle Btrfs haben die Entwickler um Funktionen zum vorausschauenden Lesen (Readahead) erweitert. Die bei Linux 3.0 eingeführte Scrub-Unterstützung wurde darauf angepasst und soll dadurch um einiges schneller arbeiten. Beim Finden beschädigter Bereiche liefert die Scrub-Funktion den Namen der betroffenen Datei. Btrfs passt die Zuordnungstabellen jetzt auch ohne expliziten Scrub-Lauf an, wenn es einen Lesefehler durch Verwenden einer zweiten Kopie der Daten des selbstständig umschiffen kann.

Falls der bei Btrfs sehr wichtige Root-Knoten beschädigt ist, kann man das Dateisystem über die neue Mount-Option "-o recovery" jetzt zur Verwendung eines alternativen Root-Knotens auffordern; der Kernel versucht dann einen älterer Root-Knoten und damit einen älteren Dateisystem-Stand einzubinden, damit man zumindest die darüber erreichbaren Daten noch retten kann.

Einige Änderungen an internen Log-Funktionen zum Verbessern der Btrfs-Performance sind wider Erwarten nicht in 3.2 eingegangen, weil sich in letzter Minute Probleme fanden, wie Chris Mason in seinem Git-Pull-Request erläutert; in dem beschreibt er auch noch einige andere für 3.2 aufgenommene Verbesserungen. In einem zweiten Anfrage hat er zum RC3 noch einige Änderungen nachgeliefert; dabei erwähnt er explizit Korrekturen (u. a. 1) für ein Problem, das bislang bei Abstürzen oder Stromausfällen zu Dateisystemschäden führte, wenn gewissen Umgebungsbedingungen gegeben waren.