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

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

Einige Änderungen machen Btrfs robuster gegenüber unerwarteten Abstürzen. Ext4 bündelt Bereiche der Platte zu Clustern, was in einigen Szenarien deutlich mehr Tempo verspricht. Auch CIFS soll erheblich schneller werden.

vorlesen Druckansicht 11 Kommentare lesen
Lesezeit: 9 Min.
Von
  • Thorsten Leemhuis
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.

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.

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.

  • Einige Änderungen am CIFS-Dateisystemcode zum Zugriff auf Samba- oder Windows-Freigaben sollen den Datendurchsatz in bestimmten Situationen erheblich steigern (1, 2, 3).
  • Die Objects Raid Engine (ORE) des Dateisystemss Exofs (EXtended Object File System) für Object Storage Devices (OSDs) beherrscht ab 3.2 auch RAID 5 (1, 2, 3). Es ist die dritte RAID-5-Implemetation des Kernels und auch Btrfs soll noch eine erhalten; langfristig ist eine Konsolidierung dieser Code-Pfade vage angedacht.
  • Christoph Hellwig nennt in seinem XFS status update for October 2011 einige der Verbesserungen an XFS; darunter Optimierungen beim Ausführen von fsync(2) bei Verzeichnissen und ein Reduzieren der Latenz bei sync(2).

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele der Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs auf Kernel.org, der die gemeinhin als "offiziell" bezeichneten Kernel-Quellen enthält. Der über diese Links angezeigte Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderung.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien; diese enthalten die Konfigurationsoptionen samt der zugehörigen Hilfetexte, die bei der Kernel-Konfiguration über "make menuconfig" oder "make xconfig" angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" kennzeichnet Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

Btrfs

Ext-Familiy

Various

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl) (thl)