Was Microsoft mit Storage Spaces im Jahr 2012 als neue Technologie vorstellt, ist Unix-Anwendern bereits seit 1990 bekannt. Ein flexibles Volume Management gehört zum Linux/Unix-Alltag und neue Dateisysteme gehen noch einen Schritt weiter.

Max Lessel

Ursprünglich waren die Festplatte und das darauf aufsetzende Dateisystem eine weitgehend feste Einheit. Bereits Anfang der 90er brach IBM mit der starren Verbindung und führte mit dem »Logical Volume Manager« (LVM) ein neues Konzept ein, das alle Unix-Derivate übernahm. Der heutige Linux-LVM hat seinen Ursprung in der Implementierung von HP-UX aus dem Jahr 1995.

Die verfügbaren Platten eines Servers verwaltet der LVM als so genannte »Physical Volumes« (PV). Mehrere Volumes fasst der Verwalter dann in einer »Volume Group« (VG) zusammen, einem Pool aus Speicherblöcken. Aus diesem Pool heraus generiert der LVM dann »Logical Volumes« (LV) und erst auf diese setzt das Dateisystem auf. Der Administrator kann dabei vorgeben, dass ein Volume über mehrere Physical-Volumes verteilt angelegt wird. Damit erhöht sich die Geschwindigkeit. Um RAID-Level kümmert sich der LVM dabei allerdings nicht. Das ist entweder die Aufgabe eines physischen RAID-Controllers. Alternativ setzt das System auf Software-RAID, wobei diese Funktion unabhängig noch unter dem LVM liegt.

Unter Linux steht es dem Anwender relativ frei, welches Dateisystem er auf seinen LVs verwendet. Bestehende Volumes lassen sich zur Laufzeit mit freien Blöcken aus der VG erweitern. Das macht nur dann Sinn, wenn ein Dateisystem zum Einsatz kommt, das sich zur Laufzeit erweitern lässt. Gehen der VG die freien Blöcke aus, kann der Administrator weitere Disks nachrüsten und damit die VG erweitern.

Der LVM liefert dabei aber noch ganz andere Funktionen. Ein fester Bestandteil sind Snapshots. Dabei hält das System den Zustand eines LV zu einem bestimmten Zeitpunkt fest. Wichtig ist dabei allerdings, dass das Dateisystem über den bevorstehenden Snapshot informiert ist und alle offenen Dateien schließt. Dateisystem wie XFS verfügen dafür über eigene Kommandos (xfs_freeze).

Dateisysteme für den LVM

Grundlage Journal: Alle modernen Dateisysteme setzen ein Journal ein. Dort werden alle Schreibvorgänge bis zum Zeitpunkt ihrer Fertigstellung protokolliert. Stürzt ein Rechner im laufenden Betrieb ab, muss der Prüfvorgang nicht das komplette Dateisystem nach offen gebliebenen und damit beschädigten Dateien suchen. Ein Blick ins Journal genügt. Nur ext2 und die Windows-Dateisysteme FAT16/FAT32 und exFAT arbeiten heute noch ohne Journal.

ext4: Die vierte Version des Ur-Linux-Dateisystems. Funktioniert unter jeder Linux-Distribution.

jfs: Journaling Dateisystem von IBM, das 1990 mit AIX 3 eingeführt und später auch für OS/2 verwendet wurde. Sehr stabil vor allem bei großen Dateisystemen.

xfs: Performantes und stabiles Dateisystem, das SGI 1994 für Irix entwickelte und in der Zwischenzeit unter GPL freigegeben hat.

LVM inklusive

Noch einen Schritt weiter gehen die Dateisysteme ZFS und BTRFS, ironischer weise jetzt beide in der Hand von Oracle. ZFS integriert LVM, RAID, Kompression und Deduplikation in einem Dateisystem. Das läuft bevorzugt unter Solaris aber auch auf BSD. Da ZFS jedoch nicht unter GPL-Lizenz weiter gegeben wird, darf es nicht Teil des Linux-Kernels werden. Hier läuft es nur als Filesystem im Userspace (FUSE) und damit langsamer als Kernel-Dateisysteme.

BTRFS hingegen steht unter GPL und wird in Kürze wohl zu einem der Standard-Dateisysteme von Linux. BTRFS beherrscht (noch) nicht alle Funktionen von ZFS. Die integrierten RAID-Features fehlen ebenso, wie die Deduplikation. Dafür integriert sich der Rest vorzüglich in Linux. Trotz der großen Funktionsvielfalt lassen sich ZFS und BTRFS kinderleicht über wenige Befehle verwalten.

File-Dateisysteme

Linux ist es im Prinzip egal, ob es ein Dateisystem auf einem Block-Device generiert (Disk) oder in einer Datei, welche dann selbst auf einem anderen Dateisystem liegt. Das Loop-Device behandelt eine Datei wie eine Disk. Ein prominentes Beispiel ist die Option, ISO-Dateien direkt als CD/DVD zu mounten.

Ein anderes Einsatzgebiet ist die Virtualisierung mit Xen oder KVM. Hier kann der Anwender Dateien im Host-Filesystem erstellen, welche später den VMs als virtuelle Disks dienen. Das Ganze arbeitet mit Thin-Provisioning, da nur die geschriebenen Blöcke Platz belegen, während die Datei Raum für mehr Speicher vorgaukelt. Neben RAW-Dateien eignet sich hier auch das QCOW2-Format (QUEMU Copy on Write). Im Prinzip stellt das eine virtuelle Disk dar, erlaubt aber Snapshots und Differenzklone. Mehrere VMs können ein QCOW2-Image als Basis-Disk verwenden, die Writes aber auf getrennte Differenzdateien schreiben.

Vernetzte Dateisysteme

Weitere Ansätze verteilen Dateisysteme in Clustern auf mehrere Knoten. Neben kommerziellen  Implementierungen wie Quantums »StorNext« und »GPFS« von IBM gibt es dabei auch leistungsstarke, freie Lösungen. »GlusterFS« läuft auf mehreren Cluster-Nodes, verwaltet aber einen Single Namespace. Es stellt sich nach außen also wie ein einziges Dateisystem dar. Gluster kann dabei die Daten auf den Nodes nur verteilen, sie spiegeln oder eine Kombination von Spiegelung und Verteilung einsetzen. Vereinfacht gesagt: Gluster FS lässt sich auch als Netzwerk-RAID missbrauchen. Das Dateisystem ist Bestandteil des RedHat Storage-Servers findet sich aber auch in anderen Distributionen wie Ubuntu.

Fazit

Mit 22 Jahren Verzögerung rüstet Microsoft das kommende Windows nun mit einem LVM aus. In der Zwischenzeit haben sich die Dateisysteme in der Linux/Unix-Welt enorm weiter entwickelt und rücken von diesem Konzept schon wieder ab. Lösungen wie das verteilte Gluster FS und VMwares »CloudFS« (siehe Kasten) stellen eingeführte SAN/NAS-Architekturen in Frage, denn hier erreichen mehrere handelsübliche Server mit lokalen Platten hochverfügbare Daten ohne die Kosten einer teuren SAN-Architektur.