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

Inhaltsverzeichnis

Auch in dieser Woche hat Linus Torvalds in der Nacht von Montag auf Dienstag eine neue Vorabversion von Linux 3.0 freigegeben. In der Freigabemail zum mittlerweile vierten RC erwähnt er einige etwas umfangreichere Änderungen am DRM-Subsystem; darunter Patches, welche die zwischen RC2 und RC3 eingeflossene Unterstützung für den Grafikkern in AMDs kürzlich vorgestelltem Llano verbessern.

Das Kernel-Log nimmt die fortschreitende Entwicklung von Linux 3.0 zum Anlass, die Mini-Serie "Was 3.0 bringt" mit der Beschreibung der Neuerungen rund um Dateisysteme fortzusetzen. Den Anfang dieser Artikel-Reihe hatte eine Übersicht der Änderungen an Netzwerk-Treibern und -Infrastruktur gemacht; in den kommenden Wochen werden Artikel zur Grafik-Treibern, Architektur-Code, Storage-Unterstützung, Infrastruktur und Treibern für andere Hardware folgen.

Btrfs

Einen ganzen Schwung von Änderungen gab es am weiterhin experimentellen Btrfs-Dateisystem; der bei Oracle beschäftigte Hauptentwickler Chris Mason bezeichnete sie in seinem Git-Pull-Request als die vermutlich umfangreichsten, die er je eingesandt hat. Zwischen RC1 und RC2 legt er sogar nochmal einige umfangreichere Änderungen nach – Torvalds kritisierte Letzteres jedoch scharf und forderte die Btrfs-Entwickler auf, solch große Änderungen nicht wieder nach Ende des Merge Window einzusenden.

In diesen und früheren Git-Pull-Request zeigt sich auch deutlich, wie viele verschiedene Firmen mittlerweile zu Btrfs beitragen. Fujitsu-Entwickler Miao Xie hat etwa die neue "Delayed Inode Items Operation" eingebracht; laut Messungen des Entwicklers beschleunigt die Technik das Erstellen von Dateien um zirka 15 Prozent, das Löschen um 20 Prozent.

Von Arne Jansen stammt die Scrub-Unterstützung; hier liegt das Copyright bei Strato. Über diesen Code kann der Anwender den Kernel anweisen, alle Daten vom Speichermedium zu lesen und dabei die Checksummen zu prüfen, um sicherzustellen, dass alle Daten intakt sind; findet es Fehler, dann versucht das Dateisystem eine intakte Kopie des Blocks einzubinden, wenn es eine finden kann.

Den Code zum Verwalten von Inodes haben die Entwickler überarbeitet, damit die Inode-Nummern auf 32-Bit-Systemen nach Löschen und Anlegen vieler Dateien nicht ausgehen; in dem Rahmen erhielt das Dateisystem einen Cache für freie Inode-Nummern, der aber fürs erste über eine Mount-Option eingeschaltet werden muss, weil er noch Probleme bereitet. Diese Verbesserungen hat Fujitsu-Entwickler Li Zefan vorangetrieben.

Da Btrfs mit Copy on Write (COW) arbeitet, fragmentiert es bei bestimmten Zugriffsmustern schnell. Über die neue Mount-Option "auto_defrag" kann man das Dateisystem nun anweisen, auf kleine und zufällige Schreiboperationen ("small random writes") in existierenden Dateien zu achten, um solche Dateien zur automatischen Defragmentierung vorzumerken. Das ist laut Commit-Kommentar und Git-Pull-Request gut für kleine Datenbanken wie jene von Sqlite oder die BerkeleyDB geeignet, nicht aber für größere Datenbanken oder die Festplattenabbilder von Virtualisierungslösungen.

Diese Änderung stammt von Mason selbst. In einem der Git-Pull-Requests hebt er außerdem noch einige Performance-Optimierungen hervor, die Red-Hat-Entwickler Josef Bacik eingebracht hat; zudem habe Suse-Entwickler Dave Sterba zahlreiche Aufräumarbeiten vorgenommen.

In einer Diskussion um den Einsatz von Btrfs als Standard-Dateisystem bei Fedora 16 erwähnte Bacik kürzlich, ein besseres Werkzeug zum Checken und Reparieren von Btrfs-Dateisystem sei "so gut wie fertig"; die Freigabe des seit Monaten vorbereiteten Werkzeugs verzögere sich aber, weil es sehr ausführlich getestet werde. Das derzeit verfügbare btrfsck/fsck.btrfs bietet nur einige Basis-Funktionen.