Dateisysteme – Fünfte Generation

In meinem vorherigen Artikel wurden einzelne Dateisysteme verschiedenen Generationen zugeteilt. Wie man aus der Zuteilung erkennen kann, verwendet die Mehrzahl der privaten Haushalte (zwangsweise, schließlich hat Windows hier die Marktmacht) ein Dateisystem der vierten Generation. Das bedeutet wir haben Ordner und Dateien, dazugehörige Metadaten wie Nutzer, Gruppen, deren Berechtigungen, Hard- und Softlinks um Dateien und Ordner sowohl innerhalb als auch außerhalb einer Partiton zu verlinken, Prüfsummen für Metadaten sowie ein Journal, welches die Konsistenz des Dateisystems schnell feststellen lässt.

Die Frage die sich hier zwangsweise stellt: Wozu brauchen wir dann überhaupt ein neues Dateisystem? Wir stoßen noch lange nicht an die Limitierungen der aktuellen Dateisysteme, und doch haben diese ein paar gravierende Nachteile, die unter anderem auch mit den immer größer werdenden Speicherkapazitäten zum Vorschein kommen dürften.

Als Dateisystem der "fünften Generation" gehe ich im Folgenden vor allem auf btrfs ein. Einerseits, weil ich von ZFS nicht viel Ahnung habe, andrerseits, weil btrfs für Privatanwender den neuen Standard darstellen dürfte und daher am meisten Interesse wecken sollte.

Features im Überblick

Btrfs zeichnet sich vor allem durch folgende Fähigkeiten aus:

Copy-on-Write (CoW)

Eine der größten Neuerungen stellt Copy-on-Write (CoW) dar. Hierbei werden geänderte Datenblöcke nicht direkt überschrieben, sondern zunächst an einen freien Speicherplatz kopiert. Danach werden die Metadaten hierzu geändert und die alten Blöcke anschließend freigegeben. Vorteil dieser Methode ist, dass sich das Dateisystem immer in einem konsistenten Zustand befindet, auch wenn das System abstürzt oder die Stromversorgung während eines Schreibvorgangs unterbrochen wird. Zudem bildet diese Technik die Grundlage für die effiziente Verwaltung von Snapshots.

Allerdings ist CoW für große Dateien, welche häufig geändert werden, ungeeignet. Das trifft unter anderem auf virtuelle Maschinen zu. Natürlich haben die Entwickler auch daran gedacht, sodass sich CoW mit dem Befehl chattr +C "name" für Dateien und Ordner auch deaktivieren lässt. Da viele Features auf CoW aufbauen sollte man dies allerdings nur dann anwenden, wenn es unbedingt nötig ist.

Kompression

Die Mehrheit der Dateisysteme bringt keine integrierte Kompression mit (von NTFS einmal abgesehen, sofern man diese denn aktiviert), btrfs hingegen bietet sogar mehrere Möglichkeiten:

  • zlib – gute Kompression, mittelmäßige Geschwindigkeit
  • lzo – mittelmäßige Kompression, hohe Geschwindigkeit
  • Keine Kompression (aktueller Standard)

In Zukunft sollen auch noch weitere Verfahren integriert werden (etwa lz4 oder auch snappy), wodurch man sich auch die Möglichkeit offen lässt nachträglich bessere Verfahren zu entwickeln, ohne das Dateisystem selbst verändern zu müssen.

Die Kompression unter btrfs ist zudem "intelligent", eine Datei wird nur dann komprimiert abgelegt wenn eine Kompression tatsächlich Vorteile bringt. Dies stellt einen Unterschied zu den bisher gängigen Verfahren dar, welche weitgehend entweder keine Kompression einsetzen oder ein bestimmtes Verfahren erzwingen, welches dann allerdings bei der Mehrheit der Daten zu merklichen Leistungseinbußen führt.

Prüfsummen

Prüfsummen stellen die Datenintegrität sicher. Immer, wenn ein Block gelesen wird überprüft btrfs zusätzlich, ob die Daten noch intakt sind. Ist auch für die Daten eine Redundanz eingerichtet (entweder via Duplizierung der Daten oder entsprechende RAID-Level), kann btrfs den Fehler automatisch korrigieren. Die Daten unterliegen daher einer begrenzten "Selbstheilungsfähigkeit". Mittels Scrubbing lassen sich zudem fehlerhafte Daten erkennen. Näheres gibt es unter dem Stichwort Data rot/degradation zu erfahren.

Deduplizierung

Auch wenn ich unter Prüfsummen den Vorteil von Prüfsummen in Kombination mit Duplizierung angesprochen habe, ist auch das Gegenteil möglich. Dadurch, dass wir von jedem Block (~128KB) eine Prüfsumme haben, können wir auch doppelt vorhandenen Blöcke erkennen und diese dank der Copy-on-Write-Fähigkeit zur Deduplizierung freigeben. Auf meinem Testsystem konnte ich so von insgesamt 185GB Daten etwas mehr als 14GB freigeben.

Möglich ist dies beispielsweise mit dem Programm duperemove. Btrfs soll langfristig eine sogenannte in-band-deduplication erhalten, d.h. die aktuell noch manuelle Deduplizierung würde dann bereits automatisch beim Schreiben von Daten greifen, und Tools wie duperemove damit (weitgehend) überflüssig. Allerdings benötigt die Deduplizierung auch einiges an Ressourcen, da das Betriebssystem ständig alle Prüfsummen aller Blöcke vorhalten müsste. Das lohnt sich nur begrenzt, und möglicherweise ist deshalb eine out-of-band-deduplication doch das sinnvollste.

RAID-Funktionalität

Auch wenn Hardware-Controller noch immer diverse Vorteile bieten, so ist eine in das Dateisystem integrierte RAID-Lösung doch in vielerlei Hinsicht von Vorteil, die mit separaten Controllern nur mit viel Aufwand oder auch gar nicht möglich ist. Bei einem Rebuild ist das Dateisystem beispielsweise in der Lage, nur die tatsächlich anfallenden Daten zu replizieren, während ein separater Controller alle vorhandenen Daten (und damit unnötigerweise auch freie Speicherbereiche) wiederherstellt. Bei auftretenden Fehlern, etwa Data rot, kann btrfs zudem automatisch den Block aus den Paritätsinformationen wiederherstellen. Auch bezüglich der Geschwindigkeit liegt btrfs bei meinen Test (RAID0, RAID1 und RAID5) an der Leistungsgrenze der einzelnen Festplatten, d.h. ein separater Controller hätte bezüglich der Geschwindigkeit hier keinen Vorteil.

Allerdings, und das ist noch ein großes Manko: Die Datenrate beim Rebuild einer Festplatte lag bei mir im Schnitt (allerdings nur bei RAID5) bei etwa der Hälfte des maximal möglichen. Ich konnte leider nicht herausfinden woran dies lag, zudem es auch einen Unterschied machte ob man eine fehlerhafte Festplatte direkt ersetzte oder den Umweg über hinzufügen einer neuen und entfernen der defekten Festplatte ging (beides sollte eigentlich eine ähnlich hohe Geschwindigkeit bieten, das direkte ersetzen ließ bei mir allerdings die Datenrate auf ein unterirdisches Maß einbrechen).

An dieser Stelle sei zudem darauf hingewiesen, dass die RAID5/6-Funktionalität in btrfs grobe Fehler aufweist, die einen produktiven Betrieb nicht zulassen. Wenn man die integrierte RAID-Funktionalität nutzen möchte muss man im Moment daher zwingend auf RAID0, RAID1 oder die Kombination RAID10 setzen.

Btrfs bietet zudem die Möglichkeit der Online-Konvertierung an, d.h. das System kann im laufenden Zustand den RAID-Level wechseln. Und bevor jemand fragt: Natürlich habe ich das ausprobiert, einmal von RAID5 zu RAID1 und wieder zurück zu RAID5. Erstaunlicherweise klappte das in meinem Test trotz der Fehler in der RAID5-Implementierung problemlos.

Scrubbing

Scrubbing bietet die Möglichkeit, alle vorhandenen Daten auf ihre Integrität zu testen. Btrfs liest dabei alle Daten ein, erzeugt daraus entsprechende Prüfsummen und vergleicht sie mit denen, die in den Metadaten gespeichert sind. Damit lässt sich überprüfen, ob die vorhandenen Daten noch intakt sind oder etwa durch Data rot/degradation bereits fehlerhaft sind. In Kombination mit der RAID-Funktionalität kann btrfs die fehlerhaften Daten automatisch wiederherstellen, sofern noch mindestens eine Kopie der Daten intakt ist.

Wie oft man Scrubbing ausführen möchte ist wiederum eine Frage für sich. Manche verzichten vollständig darauf, andere lassen den Vorgang automatisch alle zwei bis vier Wochen laufen. Es empfiehlt sich den Vorgang regelmäßig auszuführen, um das Risiko eines Datenverlusts frühzeitig erkennen zu können und dadurch auch deutlich zu minimieren.

Snapshots

Snapshots sind Momentaufnahmen eines Verzeichnisses. Durch Copy-on-Write brauchen diese zudem so gut wie keinen Speicherplatz und man hat trotzdem die Möglichkeit, zu einem beliebigen gesicherten Zeitpunkt zurückzuspringen. Mittlerweile gibt es erste Ansätze dieses Verfahren für Systemupdates zu nutzen, um im Falle eines Falles auf den vorher definierten Zustand zurückspringen zu können. Im Prinzip, auch wenn der Vergleich etwas hinkt, eine Möglichkeit der Systemwiederherstellung wie man sie auch von Windows kennt, nur mit wesentlich ausgefeilterer Technik im Hintergrund.

Subvolumes

Was genau Subvolumes sind ist schwierig zu beantworten, man kann sie sich aber als eine Art LVM innerhalb von btrfs vorstellen. Subvolumes ermöglichen es, eine bestehende btrfs-Parition nochmals zu unterteilen, wobei die einzelnen Volumes den gesamten Speicherplatz teilen. Man kann dadurch die Vorteile von btrfs übergreifend zwischen mehreren Volumes nutzen. Für Subvolumes können zudem Quotas definiert werden, ich kann also sagen, dass das Subvolume für das Homeverzeichnis maximal 30GB beanspruchen darf, auch wenn auf dem Datenträger noch mehr Speicherplatz zur Verfügung stehen würde. Gleichzeitig bin ich aber flexibel, da Quotas jederzeit verändert werden können.

Fazit

Insgesamt ein recht interessantes Thema, gerade wenn man sieht, welche Möglichkeiten sich dadurch eröffnen. Alles, was bisher jeweils separat konfiguriert werden musste (RAID, LVM), fasst btrfs in einem Stück zusammen und bietet dabei auch noch eine Flexibilität, die anders gar nicht möglich wäre. Dazu gibt es dann noch Snapshots, Copy-on-Write, Deduplizierung und diverse andere Späße. Anders formuliert: Wer langfristig nicht auf solche Dateisysteme setzt hat entweder gute Gründe (denn btrfs ist auch nicht für jeden Anwendungsfall geeignet) oder, so anmaßend das auch klingt, logisch nicht nachvollziehbare Ängste vor neuen Technologien.

Alternativ auch einfach keinen Bedarf für die neuen Funktionen. Dann stellt sich aber die Frage, warum man dann Dateisysteme der – beispielsweise – vierten Generation einsetzt, wenn man auch noch ältere Dateisysteme verwenden könnte. Fragen über Fragen…