Wenig hat sich so verändert wie die Welt der Filesysteme: In 20 Jahren wuchs der Platz, den sie verwalten, auf das Dreitausendfache und mehr. Dank neuer Features halten sie dieses Tempo mit.

“Da Files unabhängig von den laufenden Prozessen beziehungsweise dem Betriebssystem existieren, müssen sie in Verzeichnissen in vereinbarter Form auf dem Datenträger registriert sein. Dazu existiert ein Fileverzeichnis auf jedem Datenträger.” Das ließe sich ohne Weiteres unterschreiben. Stutzig wird man allerdings bei den Beispielen, die der Autor des Zitats dann heranzieht: “Das kann vollständig auf einem gesonderten Bereich des Datenträgers erfolgen (OS/ES, CP/M) oder in einem Wurzelverzeichnis und im Filesystem selbst (VMS, RSX-11, Unix, MS-DOS).”

CP/M? Richtig, das Zitat stammt aus einem gut 20 Jahre alten Wälzer über Betriebssysteme [1]. Danach scheint sich jedenfalls an der Funktion der Filesysteme in den letzten zwei Jahrzehnten nichts Besonderes geändert zu haben. Lohnt es sich überhaupt noch, immer wieder Artikel darüber zu schreiben?

Einen Fingerzeig auf die Antwort liefert ein Blick auf die Medien, von denen damals die Rede war: Der SCSI-Standard hatte eben das Licht der Welt erblickt (1986). Im Erscheinungsjahr des Buches definierte die Universität Berkeley erstmals den Begriff Raid. Für Heimcomputer waren Musikkassetten oder 5,25-Zoll-Floppies als Massenspeicher gang und gäbe. Der Profi arbeitete schon mit Festplatten, aber die fassten ein paar Dutzend, maximal wenige Hundert Megabyte und waren so teuer, dass eine heutige Terabyte-Disk zu den damaligen Preisen (5,2 Dollar/MByte) mehr als 3,6 Millionen Euro kosten müsste.

Größenexplosion

Tatsächlich kostet sie um die 150 Euro, tatsächlich ist sie vieltausendmal größer als zu der Zeit, aus der das Zitat stammt, und im Moment verdoppelt sich ihre Kapazität tatsächlich jedes Jahr. Diese Größenexplosion muss sich natürlich auf die Filesysteme auswirken, die diesen Platz verwalten: Zum einen müssen sie mit weit größeren Volumina klarkommen (Abbildung 1), was im einfachsten Fall heißt, mehr Bits für die Blockadressen bereitstellen. Aber das ist nicht alles: Die Entwickler von Ext 4 haben etwa errechnet, dass ein Filesystemcheck auf einem 64-Bit-Filesystem maximaler Größe 119 Jahre laufen würde. Unpraktisch.

Auch eine moderate Beschleunigung brächte keinen Ausweg, stattdessen sind ganz andere Lösungen gefragt, um die Kapazitäten heutiger Festplatten zu beherrschen. Als Zielvorgaben stehen deshalb im Pflichtenheft der Filsesystem-Programmierer unter anderem:

• Fehlertoleranz und Selbstheilungsfähigkeiten
• Bessere Performance durch intelligente Block-Allozierung und
  geringere Fragmentierung im Betrieb (beispielsweise dank
  Extents)
• Höhere Kapazitäten und bessere Skalierung der
  Gesamtgröße, aber gleichzeitig auch der Maximalzahl
  möglicher Files und Verzeichniseinträge
• Mehr Datensicherheit durch Transaktionen, Redundanz und/oder
  Prüfsummen, damit es gar nicht erst zu einem Fehler kommen
  kann, der zu beheben wäre
• Integration von Volumemanager-Funktionen wie etwa von
  Snapshot-Mechanismen oder Raid-Konfigurationen in das
  Filesystem

Ein Filesystem, dass alle diese und noch etliche zukunftweisende Funktionen mehr bereits jetzt realisiert, ist ZFS [2] unter Solaris. In Linux wird es jedoch vermutlich nicht so bald Einzug halten, was an lizenzrechtlichen, aber auch technischen Problemen liegt. Umso mehr lohnt ein Blick auf den Stand der Dinge bei Filesystemen, die alternativ unter Linux verfügbar sind und sich für den professionellen Einsatz eignen.

Abbildung 1: Neue Technologien ermöglichten bisher immer wieder eine höhere Aufzeichnungsdichte und damit höhere Kapazitäten von Festplatten. Mit Patterned Media und Heat-assisted Recording sind bereits die nächsten Techniken am Start, die wiederum größere Platten erlauben. (Bild © Quelle: Hitachi)

Ext 3 und Ext 4

Ext 3 [3], entstanden aus einer Erweiterung des Vorgängers Ext 2 um Journaling-Funktionen, ist sicherlich das derzeit meistverwendete Filesystem unter Linux. Allerdings fehlen der inzwischen schon angegrauten Entwicklung nicht nur fortgeschrittene Funktionen wie Online-Defragmentierung, Prüfsummen, transparente Komprimierung oder Verschlüsselung, es hat mit nur 16 TByte auch ein Größenlimit, an das heutige Filesysteme in der Tat stoßen. Das Journal speichert die Metadatenblöcke außerdem – anders als XFS, JFS oder Reiser-FS – nicht komprimiert, sondern 1:1, was nicht gerade platzsparend ist.

Folgerichtig programmieren Entwickler seit 2006 am Nachfolger Ext 4 [4], der viele dieser Beschränkungen aufheben soll. Allerdings existiert bis heute erst eine Betaversion, die sich ausdrücklich nicht für den Produktivbetrieb eignet, vor allem weil sie noch mit internen Formaten experimentiert.

Geplant sind neben Features, die größere Files und Filesysteme erlauben, auch solche, die der Zuverlässigkeit und Robustheit zugute kommen, etwa Checksummen für Metadaten. Der bequeme Migrationspfad vom Vorgänger zu Ext 4, den es später einmal geben soll, wird dann für die große Anzahl Ext-3-Nutzer das überzeugendste Argument sein.

JFS

JFS [5] wurde zu jener Zeit entwickelt, aus der das Eingangszitat stammt. Das primäre Ziel war, die Wiederanlaufzeiten nach einem Systemcrash drastisch zu verkürzen. Viele bis dahin gebräuchliche Filesysteme mussten nach einem Absturz in einem fehlerträchtigen und vor allem zeitaufwändigen Prozess die gesamte Adressenstruktur des Filesystems überprüfen und gegebenenfalls bereinigen (»fsck«). Das dauerte oft Stunden und es war absehbar, dass dieser Prozess mit dem rasanten Wachstum der Festplattenkapazität bald Tage und Wochen benötigen müsste.

Dagegen setzt JFS das Journal, das es im Namen führt. Dieses Log zurückliegender Transaktionen mit Metadaten erlaubt es, das Dateisystem sehr schnell zu recovern, was hier meint, einen konsistenten Zustand der Metadaten wiederherzustellen [6]. Über die eigentlichen Daten ist damit nichts gesagt, für sie braucht man gegebenenfalls zusätzlich ein Backup.

JFS alloziert Speicherplatz für Dateien bereits so, wie die meisten später entwickelten Filesysteme, nämlich in Form ganzer Ketten zusammenhängender Blöcke, so genannter Extents. Das reduziert die Fragmentierung und ist besonders bei sehr großen Files viel effizienter als ein 1:1-Mapping physischer auf logische Blöcke. Außerdem ist JFS2 auch schon ein 64-Bit-Dateisystem und bietet damit für absehbare Zeit genug adressierbaren Raum.

XFS

XFS [7] ist ebenfalls schon ein Filesystem-Veteran, der Mitte der 90er Jahre unter der Regie von SGI für deren Unix-Derivat Irix entstand und seit 2001 auch frei für Linux verfügbar ist [8]. Es kennt fortgeschrittenere Features wie Access-Control-Listen (ACLs) oder Quotas. Im Unterschied zu JFS war bei XFS die Performance ein vorrangiges Entwicklungsziel. Deshalb schreibt XFS sein Journal beispielsweise asynchron, um andere Operationen im Filesystem damit nicht zu blockieren.

Zu den Maßnahmen im Interesse der Performance-Optimierung zählt außerdem die so genannte verzögerte Allokation von XFS, bei der der Hauptspeicher zu schreibende Daten möglichst lange puffert, um so dem Treiber eine bessere Chance zu geben, einen optimalen Platz auf der Platte zu finden. Die geringere Fragmentierung und den daraus resultierenden Geschwindigkeitsgewinn erkauft XFS sich allerdings mit einem höheren Risiko, jene Daten zu verlieren, die bei einem Crash womöglich noch nicht gesichert waren.

Reiser-FS 3

Reiser-FS [9] war das erste Journaling-Filesystem im Linux-Kernel (ab Release 2.4.1). In letzter Zeit machte eher sein als Mörder seiner Ehefrau verurteilter Schöpfer Hans Reiser Schlagzeilen, dessen langjährige Gefängnisstrafe auch die Perspektive seiner Projekte in Frage stellt. Zumindest die unter anderem von Suse gesponserte Version 3 hatte jedoch schon vor der Familientragödie eine größere Anhängerschar.

Von XFS und JFS unterscheidet sich Reiser-FS dadurch, dass es die Journaling-Funktion optional auch auf die Nutzdaten ausdehnen kann (Full Journaling). Dafür gibt es die Mount-Option »data=journal«. Ein weiterer Vorteil ist der besonders effiziente Umgang mit vielen kleinen Dateien.

Für Reiser 4 [10], eine komplette Neuentwicklung, waren interessante Fähigkeiten geplant, etwa Plugins, die Verschlüsselung und Komprimierung realisieren sollten. Im Moment steht die Zukunft des Projekts, um das sich ein ehemaliger Mitarbeiter aus Reisers Firma Namesys, kümmert, in den Sternen.

VxFS

Das von Veritas, heute Teil von Symantec, entwickelte Filesystem VxFS [11] spielt im professionellen Umfeld unter Solaris, AIX, HP-UX oder auch Linux eine Rolle als Teil der Veritas Storage Foundation. Die ist ihrerseits unter anderem Voraussetzung für den Veritas-HA-Cluster und unterstützt gezielt auch andere weitverbreitete kommerzielle Software wie Oracle RAC und andere HA-Lösungen, Windows oder diverse Datenbanken.

In diesem Umfeld ermöglicht die Storage Foundation dann Highend-Features wie Dynamic Multi-Pathing, also ein Failover der I/O-Zugriffswege bei Ausfall eines Controllers oder Kabels, Hot Relocation, also automatisches Umkopieren von Daten bei einem drohenden Plattenausfall, oder automatisiertes Tuning.

VxFS ermöglicht sehr große Files und Filesysteme und bietet unter anderem Online-Resizing und -Defragmentierung, ACLs oder Quotas. Der verwandte Veritas-Volumemanager kann dann mit Raid, Snapshots und anderen komplementären Features aufwarten.

BTRFS

Eine der interessantesten Entwicklungen der jüngsten Zeit ist das von Oracle unter freier Lizenz entwickelte BTRFS [12]. Seine Prioritäten liegen bei Fehlertoleranz und einfacher Administration. Es befindet sich jedoch noch in einem sehr frühen Entwicklungsstadium (aktuell Version 0.16) und eignet sich nicht für den produktiven Einsatz.

Allerdings darf man für die Zukunft einiges erwarten: Das Extent-basierte 64-Bit-Filesystem wird unter anderem beschreibbare Snapshots bieten, selber Spiegelung und Striping beherrschen, Subvolumes mit eigenen Wurzelverzeichnissen anlegen können, Daten und Metadaten mit Prüfsummen sichern, über einen Mechanismus zur Online-Defragmentierung verfügen und kaum Zeit für Filesystem-Checks benötigen. Unter den freien Filesystemen ist es dasjenige, dessen Featureliste der von ZFS am nächsten kommt.