Linux - Welches Dateisystem soll ich wählen?

In der langen Entwicklungszeit sind viele Dateisysteme entwickelt worden, die allesamt Vorzüge und Nachteile besitzen. Viele Linux-Distributionen nehmen den Usern die Entscheidung darüber ab, indem sie in der geführten Installation ein bestimmtes Dateisystem vorgeben.

Im Internet sind bereits sehr viele Artikel über die unter Linux nutzbaren Systeme vorhanden, deshalb werde ich hier nur über das von mir bevorzugte Dateisystem BTRFS (B-Tree-FS) schreiben. Ich weiß, dass es über den Entwicklungsstand und die Fähigkeiten auch kontroverse Diskussionen gab und gibt. Ich verfolge die Entwicklung seit mehr als 10 Jahren (BTRFS wurde 2008 vorgestellt), und seit 2014 benutze ich es als Standarddateisystem bei meinen Linux-Rechnern.

Pro:

  • Prüfsummen für Daten und Metadaten (Datenintegrität), jetzt mit mehreren Arten (crc32,xxhash, sha256, blake2b).
  • Ein fast beliebig großes Dateisystem (als Volume), das aus beliebig vielen Devices (z.B. Festplatten usw.) bestehen kann.
  • Im laufenden Betrieb (Online) vergrößern und verkleinern des Systems, sowohl hinsichtlich der Gesamtgröße als auch einzelner Devices. Das ergibt eine völlige Flexibilität bei der Nutzung von vorhandenen Speichermedien.
  • Integration von Teilen eines herkömmlichen Linux-Volume-Managers, d.h. Anzahl der Devices ändern, Snapshots erstellen, Raid-Funktionen nutzen, (logical) Subvolumes erstellen.

Kontra:

  • Als CoW-Dateisystem (copy-on-write) nicht für alle Anwendungsfälle gleich gut geeignet, z.B. große Datenbanken.
  • Einarbeitung in die Handhabung des Dateisystems erforderlich, da einige Werkzeuge (fsck.btrfs…) und Raid-Funktionen (Raid 0,1,10,5,6) sich grundlegend von denen anderer Dateisysteme unterscheiden.
  • keine automatische Wiederherstellung eines defekten Raids (z.B. Spare Device). Es ist immer situationsabhängig ein manueller Eingriff nötig.

Bei der Abwägung überwiegen für mich die Vorteile der konsistenten Datenspeicherung und die Änderungen an Datenträgern im laufenden Betrieb. Seit 2014 betreibe ich einen Server, der mit hotplugfähigen Festplatteneinschüben versehen ist. So ist jederzeit eine Umkonfiguration und Erneuerung im laufenden Betrieb möglich. Ein Server-Motherboard ermöglicht den Einsatz von ECC-RAM, was die Datensicherheit weiter erhöht. Es gab bis heute keinen Datenverlust, BTRFS erwies und erweist sich als zuverlässig und stabil.

Es liegt oft an dem Missverständnis, dass BTRFS genauso wie die übrigen Dateisysteme funktioniert bzw. funktionieren soll! Die Organisation aller (Meta-)Daten in B-Bäumen ist komplexer als die Verwaltung linearer Datenblöcke, Fehler sind nicht so einfach zu beheben. Die Reparaturwerkzeuge sind zwar immer weiter entwickelt worden, doch können sie noch nicht alles vollständig beheben. Die gespeicherten Nutzdaten sind in aller Regel, wenn sie nicht durch Bedien- oder Hardwarefehler überschrieben wurden, auslesbar.

Die Stolpersteine:

  • Das BTRFS-Dateisystem sollte niemals vollständig gefüllt werden. Als CoW-Dateisystem braucht es für jede Änderung einen Platz für die geänderten (Meta-)Daten. Ist dieser nicht mehr vorhanden, so gibt es eine Fehlermeldung und das Dateisystem ist nur noch lesbar eingehängt. Jetzt ist guter Rat teuer, denn es ist nicht mehr einfach möglich, Daten zu löschen, um den Platz wieder frei zu machen. Auch eine Dateilöschung benötigt neue Metadaten, die auf das volle Dateisystem nicht geschrieben werden können. Nun sind Kenntnisse und BTRFS-Befehle nötig, um das Problem zu lösen. Übrigens hatte in frühen Linux Zeiten reiserfs ebenfalls ein Problem mit vollem Dateisystem, eine Wiederherstellung war damals nicht möglich. BTRFS erlaubt das Hinzufügen von Datenträgern und kann auf diese Weise leeren Platz schaffen.
  • BTRFS-Raid ist kein Raid im alten Stil, wie es als Software- oder Hardware-Raid bereitgestellt und genutzt wird. Die Begriffsgleichheit kann Verwirrung stiften, solange man sich nicht in BTRFS eingearbeitet hat. Dieser „Geburtsfehler“ sorgt immer wieder auch bei den „Profis“ für das katastrophale Missverständnis, das es unter BTRFS genau so funktioniert wie unter anderen Systemen. Traditionelles Raid verlangt konstante, gleiche Partitionsgrößen im jeweiligen Raid-System. Da BTRFS auch Raids mit unterschiedlich großen Datenträgern oder Partitionen ermöglicht und diese effizient mit der maximal möglichen Datenmenge arbeiten sollen, wird nicht die Größe des Datenträgers (Partition) sondern variable, einzelne Chunks (default data=1G meta=256M) für seine Art Raid-System verwendet.
  • Für Server, die ununterbrochen Dienste bereitstellen, ist die Hardwareverfügbarkeit ein Kriterium, das Raid-Systeme (Hard- oder Softwaremäßig) verbessern können. Im SOHO-Bereich (Small-Office/Home-Office) zeigt sich BTRFS-Raid in seiner Version 1 (Mirroring) seit einiger Zeit sehr stabil und kann mit dem Ausfall eines Datenträgers im Verbund weiterarbeiten. Die Handhabung, wie dann wieder der normale Zustand hergestellt werden kann, ist nicht automatisiert und erfordert erweiterte Kenntnisse (Befehle in der Kommandozeile). Bei hotplugfähigen Datenträgern funktioniert das im laufenden Betrieb. Es gibt noch kein einfaches Werkzeug (Programm) zur ständigen Überwachung auf Schreib- und Lesefehler im BTRFS-System, die zeitnahe Auswertung des/der Logfiles ist z.Zt. die beste Lösung, um schnell eine Störung zu beheben. Aufgepasst: z.B. drei Festplatten im BTRFS-Raid1 ergeben nicht gespiegelte Daten auf jedem Datenträger (3x), sondern es gibt immer genau 2x Daten auf unterschiedlichen Datenträgern. Das gilt auch, wenn noch weitere Datenträger im BTRFS-Raid1 vorhanden sind. Die Zahl sollte nicht zu hoch gewählt werden, da steigt die Ausfallwahrscheinlichkeit im großen Verbund statistisch stark an und es droht doch noch ein kompletter Datenverlust, wenn im Wiederherstellungszeitraum ein weiterer Defekt an einem anderen Datenträger auftritt.
  • BTRFS-Raid(s) kopieren für die Wiederherstellung nicht einfach Sektor für Sektor eine 1:1 Kopie wie bei traditionellen Raids, sondern nur die Bereiche, die Daten enthalten. MBR und GPT Sektoren sind nicht dabei, z.B. Grub muss danach manuell auf den Ersatzdatenträger gebracht werden. Das bedeutet auch, dass dieser bereits passend partitioniert sein muss, bevor er in den Verbund eingefügt wird. BTRFS funktioniert zwar auch mit Datenträgern, die keine Partitionen enthalten, sie können dann nur Daten enthalten und es kann nicht von diesen gestartet werden.

In einem weiteren Beitrag werde ich meine Anwendungsfälle und Vorgehensweise beschreiben…

(rw)