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

Mit der nächsten Kernel-Version erreicht Ext4 neue Leistungsdimensionen und kann Datenträger durch einen Trick flotter formatieren. Neu sind auch eine Discard-Funktion, die für langsam trimmendende SSDs interessant ist, das "Rados Block Device" für Block-Devices im Cluster sowie Fehlerkorrekturen und Optimierungen an Btrfs.

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

Die Freigabe des RC4 des für den Jahreswechsel erwarteten Kernels 2.6.37 vor wenigen Tagen nimmt das Kernel-Log zum Anlass, die Mini-Serie "Was 2.6.37 bringt" mit der Beschreibung der Neuerungen rund um Dateisysteme fortzusetzen. Der erste Teil der Serie hatte sich mit den Änderungen rund um Grafik-Hardware beschäftigt; folgen werden in den kommenden Wochen noch Artikel zu Architektur-Code, Treibern und der sie umgebenden Infrastruktur.

Die "Lazy Inode Table Initialization" soll in Kombination mit neuen Userland-Tools das Anlegen von Ext4-Dateisystemen deutlich beschleunigen, da die für die Inode-Tabellen benötigten Bereiche beim Formatieren nicht mehr explizit bereinigt werden.

Durch die in 2.6.37 eingeflossenen Änderungen skaliert Ext4 besser und kommt näher an XFS heran.

(Bild: http://thunk.org/tytso/blog/2010/11/01/)

Der Ext4-Code arbeitet nun enger mit dem Block Layer zusammen – dadurch soll das Dateisystem deutlich schneller arbeiten, besser skalieren und gleichzeitig die CPU weniger belasten. Wie Ext3-Hauptentwickler Ted "tytso" Ts'o im Haupt-Git-Pull-Request und noch etwas ausführlicher einem Blog-Eintrag schreibt, stiegt der Durchsatz durch diese und einige bereits zuvor umgesetzte Änderungen auf einem Testsystem mit 48 Prozessorkernen auf das Dreifache und die CPU-Belastung reduzierte sich um den Faktor drei bis vier. Dadurch käme Ext4 nun recht nahe an die Leistung von XFS heran; er habe zudem noch weitere Performance-Verbesserungen geplant.

Das VFS bietet nun einen "FITRIM" genannten Ioctl, über das Programme wie das bald in die Standard-Werkzeugsammlung util-linux-ng einziehende fstrim den Dateisystem-Code des Kernels anweisen können, nach freien Bereichen zu suchen und den Datenträger darüber zu informieren – etwa per ATA_TRIM. Bislang implementiert allerdings nur Ext4 die neue Schnittelle für die auch "Batched Discard" bezeichneten Funktion (1, 2).Das Melden freier Bereiche ist für Thin Provisioning wichtig und verbessert Performance und Lebensdauer von SSDs.

Da dafür das ganze Dateisystem nach freien Bereichen durchsucht werden muss, kann solch ein Batched Discard durchaus einige Zeit in Anspruch nehmen. Wie lange anschließend der Datenträger zur Verarbeitung der Kommandos braucht, ist nicht mehr sonderlich wichtig.Manche SSDs lassen sich dabei nämlich viel Zeit, wie der Entwickler der Änderungen vor einigen Monaten bei der Vorstellung der Patches erläuterte. Daher sinkt der Datendurchsatz unter Umständen erheblich, wenn der Kernel den Datenträger direkt bei jedem Löschen einzelner Dateien über freigewordene Bereiche informiert, wie es der Kernel seit Version 2.6.33 beherrscht.

Der Entwickler bietet einige Programme für Test der Discard-Geschwindigkeitstest auf seiner Homepage zur Verfügung. Dort finden sich auch Messwerte einiger Produkte, es fehlen allerdings Hersteller-Namen und Modell-Bezeichnungen.

Einen guten Überblick über die Änderungen an Btrfs gibt der Git-Pull-Request von Chris Mason. So brachte Red-Hat-Entwickler Josef Bacik Änderungen ein, durch die das "Next Generation Linux File System" eine Liste freie Blöcke in einer speziellen Inode zwischenspeichert, sofern das Dateisystem mit "-o space_cache" eingebunden wird. Das macht das Btrfs nach einem frischen Mounten "erheblich flotter", weil die Strukturen nicht nach freien Blöcken abgesucht werden müssen. Kurz vor Freigabe der vierten Vorabversion von 2.6.37 stießen zudem noch einige Korrekturen am Btrfs-Code zum Kernel, unter anderem für Probleme, die sich beim Einsatz von Direct I/O oder beim Zusammenspiel mit NFS zeigten.

Eine umfangreiche, im Git-Pull-Request kurz erläuterte Umstrukturierung gab es beim teilweise auf dem Btrfs aufbauenden Code des Cluster-Dateisystems Ceph: Teile des Dateisystem-Codes wurden in die Kernel-interne Library libceph verlagert, auf die neben Ceph auch das neue und experimentelle Rados Block Device (RDB) aufsetzt. Ähnlich wie mit nbd oder iSCSI lassen sich damit Block Devices erstellen, deren Daten im Netz liegen – in diesem Fall in einem Ceph-Cluster. Weitere Hintergründe und eine Kurzbeschreibung der Funktion liefern ein Blog-Eintrag der Ceph-Entwickler und das Ceph-Wiki.

Der CIFS-Code zum Zugriff von Samba- oder Windows-Freigaben unterstützt nun die Mount-Option multiuser und mfsymlinks. Mit Hilfe eines neuen Idmappers kann der NFS-Client schneller und flexibler zwischen Namen und Identifikationsnummern (IDs) für Benutzer und Gruppen übersetzen – Details zur Funktion liefert die zugehörige Dokumentation. Einige Optimierungen am Readdir-Code von NFSv4 können das Auflisten von Verzeichnissen mit vielen Dateien erheblich beschleunigen, wie der Entwickler der Änderung mit Messwerten im Commit-Kommentar zeigt. Einige der wichtigsten Änderungen am NFSD-Code führt J. Bruce Fields in seinem Git-Pull-Request auf.

Einen guten Überblick über die Änderungen an XFS liefert das "XFS Status Update For October 2010" – einige Optimierungen rund um die Metadaten (u. a. 1) sollen etwa die Skalierbarkeit weiter verbessern und hätten das Entfernen von 50 Millionen Dateien in einem Test um über hundert Prozent beschleunigt.

Das Cluster-Dateisystem GFS2 gilt nicht mehr als experimentell und bietet nun Unterstützung für Fallocate. Einige weitere Änderungen an GFS finden sich im Git-Pull-Request von Steven Whitehouse; der von Joel Becker listet die wichtigsten Änderungen an OCFS2, der von Ryusuke Konishi die an NILFS2.

Der Code des VFS und der verschiedenen Dateisysteme braucht nun das Big Kernel Lock (BKL) nicht mehr. Nachdem bereits in 2.6.36 einige Änderungen gab, die die Skalierbarkeit des VFS verbessern sollen, stießen mit 2.6.37 weitere Optimierungen mit diesem Ziel zum Kernel – erneut blieben jedoch viele ähnlich gelagerte Änderungen außen vor, deren Aufnahme zuvor recht wahrscheinlich schien.
Indirekte Hauptursache dafür war Dave Chinner, der einen zweiten Ansatz zur Verbesserung der Skalierbarkeit präsentiert hatte, der sich an einigen Stellen von jenem Unterschied, den Nick Piggin gezeigt und zur Aufnahme vorbereitet hatte. Darüber entstand eine längere Diskussion. Die war zwar streckenweise recht harsch, führte allerdings auch zu Verbesserungen in beiden Patch-Sammlungen – weitere Hintergründe dazu liefert LWN.net in einem Artikel. Auch jetzt, einige Wochen nach der Hauptdiskussion, ist noch immer nicht absehbar, welcher der Ansätze bei 2.6.38 das Rennen macht; Torvalds hat allerdings angedeutet, die Patches von Piggin aufnehmen zu wollen, wenn sich die an der Diskussion und Entscheidungsfindung beteiligten Entwickler nicht einigen können.

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 mit den "offiziellen" Kernel-Quellen auf Kernel.org. Der über diese Links angezeigten Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderungen.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien, welche die Hilfetexte und Konfigurationsoptionen enthalten, die bei der Kernel-Konfiguration über "make menuconfig", "make xconfig" und ähnliche Werkzeuge 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" steht etwa für Ä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[234]

NFS

Various others

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)