Software::Systemverwaltung
Entwicklung des Tux3-Dateisystems gewinnt wieder an Fahrt
Das von Entwickler Daniel Phillips im Jahr 2008 parallel zu ext4 und btrfs entwickelte Dateisystem tux3, das 2009 zum Stillstand kam, wird jetzt wieder weiterentwickelt.
Bereits im Jahr 2000 hatte Phillips sein in Planung befindliches neues Dateisystem tux2 angekündigt, das dann aber wegen potenzieller Verletzung dreier Patente nie über die Planungsphase hinauskam. Tux2 sollte das damals wohl verbreitetste Linux-Dateisystem ext2 beerben. Der Vorteil gegenüber ext2 sollte durch ständige minimale Updates des Dateisystems erreicht werden und so die Vorteile des Journalings mitbringen, allerdings ohne den Overhead eines Journals.
Im Sommer 2008 kündigte Phillips tux3 an und konnte bis Jahresende einige Entwickler um sich scharen. Eines der Hauptziele von tux3 war damals, eine effiziente und platzsparende Datenversionierung zu bieten. Ein weiteres Ziel war es, alle Features von Suns Dateisystem ZFS zu bieten und dabei jeweils gleich schnell oder schneller zu sein. Inspiration zu tux3 kam außerdem vom Dateisystem Hammer für Dragonfly BSD und dessen Entwickler Matthew Dillon. Ab Ende 2009 lief tux3 versuchsweise im Kernel, im Februar 2009 konnte Linux erstmalig davon booten. Danach wurde es ruhig um das Projekt. Der letzte Eintrag im Quellcode-Archiv war am 16.8.2009.
In seiner Keynote zum Linux-Kongress 2010 bezeichnete Jon Corbet tux3 als einen Fehlschlag. Die Begründung war, dass die Aufnahme in den Kernel nicht rechtzeitig betrieben wurde, obwohl Tests die Lauffähigkeit bescheinigten. Stattdessen seien, so Corbet, weitere Features integriert worden.
Jetzt will Phillips einen neuen Anlauf nehmen, um ext4 Konkurrenz zu machen. In einer Mail am Neujahrstag an die Kernel-Mailingliste teilt er mit, dass Benchmarks mit dem Tool fsstress gezeigt hätten, dass tux3 bei der Geschwindigkeit erfolgreich mit ext4 mithalten und es teilweise übertrumpfen kann. Tux3, so Phillips, verbringe weniger Zeit mit Warten, erzeuge weniger CPU-Last und sei durchschnittlich schneller fertig.
»Wie ein deutsches Auto ist tux3 gleichzeitig oldschool und modern«, so Phillips. Tux3 sei ext4 näher als btrfs und arbeitet mit einer Inode-Tabelle, alloziert Blocks mit Bitmaps und speichert Attribute in Inodes. Im Gegensatz zu ext4 hält tux3 die Inodes in einem B-Baum. Außerdem nutzt es anstelle eines Journals ein sogenanntes write-anywhere log zur Wiederherstellung der Daten. Wie btrfs will tux3 eine Snapshot-Funktion bieten und ein schnelles, modernes Dateisystem zum generellen Gebrauch sein.
Eines der herausstechenden Design-Merkmale der Kernel-Implementation und laut Phillips verantwortlich für die bereits jetzt mit ext4 vergleichbare Geschwindigkeit sei die Aufteilung in ein Front- und ein Backend, das er vom Hammer-Dateisystem entliehen habe. Hierbei handhabt das Frontend sämtliche Posix Datei-Operationen im Cache, während das Backend die »Schmutzarbeit« im Hintergrund erledigt.
Das Journal will Phillips durch nicht-destruktive atomare Schreibvorgänge ersetzen. Hierzu macht er zwei Grundaussagen: Erstens erscheinen Daten auf einem Medium niemals intermediär, mit der Ausnahme von umfangreichen Schreibvorgängen, die in Deltas aufgebrochen, deren Reihenfolge aber strikt eingehalten wird. Zweitens: Wenn eine Dateisystem-Transaktion endet, bevor eine andere Transaktion beginnt, wird die zweite niemals auf ein Medium geschrieben, sofern die erste nicht auch geschrieben wurde.
Was tux3 zum produktiven Einsatz noch fehlt, ist die Snapshot-Funktion, die einer der Beweggründe für die Entwicklung war. Die Block-Allokation bedarf der Überarbeitung, um Fragmentierung zu vermeiden. Ein Filessystem-Check (fsck) ist noch nicht fertiggestellt ebenso wie die Features Block-Migration, Defragmentierung und das Verhindern doppelter Datenhaltung. Phillips hofft, dass viele hilfreiche Hände tux3 zur baldigen Fertigstellung verhelfen, und ruft auch vor allem Tester auf, ihre Erfahrungen zu berichten. Der Code von tux3 liegt auf Github zum Auschecken bereit.
