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.