© Nmedia, Fotolia.com

Die meisten Bytes pro Euro bekommt gegenwärtig, wer Festplatten mit einer Kapazität im Terabyte-Bereich kauft. Dann kosten sie auf der Straße nur noch 10 Cent pro Gigabyte. Selbst bei mittleren Unternehmen kommt so mittlerweile die Petabyte-Grenze in Sicht (Abbildung 1). Bleibt die Frage, wie solche Datenmengen zu organisieren sind. Denn wenn auch die Kapazitäten der Systeme gewachsen sind, haben die Datenstrukturen nicht unbedingt Schritt gehalten.

Während sich das Fassungsvermögen eines einzelnen Laufwerks in 20 Jahren fast vermillionenfacht hat, sind Blockgrößen nur unwesentlich gewachsen und verharren im Mehrfachen von Kilobytes. Damit fallen mehr Verwaltungsinformationen an. Ein weiterer Grund ist der sich gegenwärtig vollziehende Wechsel von einer reinen 32-Bit-Architektur hin zu immer stärker 64-Bit-basierten CPUs. Insofern ist das Ende der Fahnenstange für einige Linux-Dateisysteme durchaus in Sicht, selbst wenn für die meisten Desktops noch kein Grund zur Panik besteht.

Linux hat so viele Dateisysteme wie kaum ein anderes Betriebssystem anzubieten (Auswahl in Tabelle 1). Jedes verfolgt eine etwas andere Philosophie und hat Stärken auf unterschiedlichen Gebieten.

Abbildung 1: Festplattenkapazitäten steigen kontinuierlich an. Da fragen sich manche Admins und Entwickler, wie sie diese Datenmengen effizient verwalten sollen. Btrfs könnte eine Antwort sein.

Code kommt in die Jahre

Nachdem sein Hauptentwickler und Namensgeber auf absehbare Zeit sich nicht mehr um die Weiterentwicklung kümmern wird [1] und selbst die treuesten Distributionen auf andere Dateisysteme umschwenken, geben nur noch wenige Entwickler Reiser-Systemen eine große Zukunft. Der ehemalige Namesys-Mitarbeiter Edward Shishkin pflegt zwar immer noch Patches für aktuelle Kernel [2], doch fehlen hier offenbar die Impulse für weitere Entwicklungen.

Offiziell haben die Kernelentwickler den Schritt von Ext 3 auf Ext 4 als stabiles System vollzogen, abzuwarten bleibt allerdings, ob die Anwender in nennenswerter Anzahl mitgehen. Ext 4 ist zwar kompatibel zu Ext 3, kann allerdings seine größten Stärken, etwa Extends, nur ausspielen, wenn Anwender auf die Rückwärtskompatibilität verzichten.

Extends sind größere, zusammenhängende Datenbereiche auf einer Platte, die eine eigene Datenstruktur effizienter als die bisherigen Blöcke verwaltet. Davon profitieren besonders Programme wie Datenbanken, die große Datenmengen lesen und schreiben. Auf diese Weise reduziert sich der Grad der Fragmentierung – ein echtes Problem bei Partitionen in Terabyte-Regionen.

Aber ganz zufrieden sind die Linux-Hacker offenbar mit Ext 4 doch nicht. Der Ansatz trage zu viele Erblasten mit sich herum und sei daher noch nicht der große Wurf, so ließen Filesystem-Spezialisten auf mehreren Konferenzen wissen. Auch wenn das die Linux-Community wohl nie offen zugeben würde, hat Suns ZFS wohl ein klein bisschen dazu beigetragen, dass die Entwickler seit einiger Zeit über das Filesystem der nächsten Generation nachdenken.

Kleine Teile präferiert

Auf der Kernel-Mailingliste ist davon unter dem Stichwort Next Generation File System (NGFS) die Rede [3]. Anders als Sun sehen viele Linux-Entwickler die Entscheidung kritisch, viel Funktionalität in ein Subsystem zu legen. So integriert ZFS das Dateisystem mit einer Reihe von Werkzeugen, die Volumes, Raid-Levels und Snapshots verwalten.

Diese Aufgabe sehen sie eher dem Device-Mapper-Framework zukommen. Das DM-Subsystem verwenden immer mehr Entwickler von Erweiterungen, die auf den Block-Layer aufsetzen. Red Hat werkelt an Failover-Aufsätzen [4], in Österreich will man das beliebte DRDB an das Framework anpassen [5].

Auf die lokalen Festplatten bezogen gibt es neben der Zwischenlösung Ext 4 noch XFS. Seine Fangemeinde schwört auf die Codequalität und gute Skalierbarkeit, muss aber auch damit kämpfen, dass XFS als sehr architekturabhängig gilt. Gerade der Wechsel zu 64-Bit-Architekturen könnte Systemverwalter darüber nachdenken lassen, den Markt nach Modernerem zu durchsuchen.

Btrfs spendet Hoffnung

Der verheißungsvollste Kandidat ist hier sicherlich Btrfs [6]. Der Oracle-Angestellte Chris Mason verantwortet dessen Entwicklung, die auf B-Bäumen basiert und ebenfalls Extends umsetzt. Da ist es praktisch, dass Mason in seiner Zeit bei Novell vorrangig Reiser-FS gepflegt hat und sich mit der Materie auskennt.

Die Frage lautet nun weniger, ob Btrfs die Stelle des primären Linux-Dateisystems einnimmt, sondern eher wann. Der Code arbeitet schon seit Längerem, die Entwickler zögern jedoch noch ihn in den Kernel aufzunehmen, weil sie ihn noch mehr testen möchten und sich Datenformate noch ändern könnten. Gerüchten zufolge steht die Aufnahme in den normalen Kernel-Tree kurz bevor. Dass dies 2009 geschieht, halten viele für wahrscheinlich – schließlich hilft ein solcher Schritt meist auch einem Subsystem dabei, mehr Tester zu bekommen.

Übers Netz zur Festplatte

Doch hat das lokale Dateisystem überhaupt eine Zukunft in der sich vernetzenden Welt? Davon ist auszugehen, da an einer Stelle zwischen Benutzeranwendungen und Festplatten immer eine Instanz die Blöcke verwalten muss. Das ficht Netzwerkdateisysteme wie Samba oder NFS nicht an. Beide sind stabil und wohlgetestet. Ihre Entwickler machen nicht den Eindruck, große Neuerungen vorstellen zu wollen, vielleicht abgesehen vom diskutierten Merge von Samba 3 und 4 zu der gemeinsamen Version “Frankie”.

Auch an der Front der etwas ausgefallenen Systeme wie dem Andrew File System [7] ist es ziemlich ruhig: Sie gelten zwar nach wie vor als Herausforderung für den Admin, funktionieren aber einfach 2009 wie 2008. Einzig Oracle versucht den lokalen und Netzwerkansatz miteinander zu verbinden: Coherent Remote File System (CRFS, [8]) setzt dazu auf Btrfs auf. Ob es allerdings bereits in diesem Jahr einen Status erreicht, der es ermöglicht, es unter Produktionsbedingungen zu testen – das vermag niemand zu prognostizieren. (N. Magnus)