Die Woche: Btrfs zu schnell?
Oracle und Suse unterstützen Btrfs bereits heute, obwohl sich das Dateisystem im Feldtest noch nicht bewährt hat und offiziell noch als experimentell eingestuft ist. Auch beim Prüf- und Reparaturwerkzeug Btrfscheck preschen beide Distributoren voran und verzichten auf einen vorherigen Test durch die Linux-Community.
- Thorsten Leemhuis
Liebe Entwickler und Manager bei Oracle und Suse,
ich bewundere Euren Mut, das experimentelle Dateisystem Btrfs mit den neuesten Updates für Oracle Linux und Suse Linux Enterprise nun offiziell zu unterstützen. Es wird der Stabilisierung des als "Next Generation File System" für Linux auserkorenen Dateisystems sicher helfen, dass es jetzt verstärkt eingesetzt wird.
An Eurer Stelle könnte ich in diesen Wochen aber nicht mehr ruhig schlafen.
Klar, Ihr habt Euch das mit Sicherheit gut überlegt. Und Ihr habt auch fähige Mitarbeiter, die an Btrfs mitarbeiten und es ausgiebig testen; Btrfs-Erfinder und -Hauptentwickler Chris Mason steht ja sogar bei Oracle auf der Gehaltsliste. Aber Ihr wisst auch: Egal wie gut man Software testet, selbst bei noch so gründlichen Labortests fallen manche Fehler nicht auf, wie abstürzende Satelliten oder explodierende Raketen zeigen.
Um zahlende Kunden möglichst vor Fehler zu bewahren, habt Ihr bei Suse das Community-Projekt OpenSuse etabliert, wie es Red Hat mit Fedora vorgemacht hatte. Die kostenlos verteilten Distributionen dieser Projekte haben eine Reihe von Nutzern, die Fedora und OpenSuse unter den unterschiedlichsten Umgebungsbedingungen einsetzen. Durch die verschiedenen Nutzungsarten und die Vielzahl der in Umlauf befindlichen Hard- und Software treten so Fehler hervor, die selbst das gründlichste Testlabor nie mit einem vertretbaren Zeitaufwand hätte finden können. Anwender melden diese Fehler – und wenn man sich die Bugreports genauer ansieht, staunt man manchmal nicht schlecht, was für böse Schnitzer teilweise in Software lauern, die gemeinhin als gut abgehangen und stabil gilt.
Durch die Korrektur solcher Probleme werden die Distributionen nochmal einen kleinen Tick besser. Davon profitieren die auf Fedora respektive OpenSuse basierenden Unternehmens-Distributionen Red Hat Enterprise Linux (RHEL) und Suse Linux Enterprise (SLE) erheblich. Zusammen mit Support-Angeboten sind Firmen dann durchaus bereit, Geld für RHEL und SLE auf den Tisch zu legen – oder auch für Oracle Linux, das auf RHEL basiert.
Auf Btrfs wart Ihr bei Oracle und Suse aber offenbar so scharf, dass Ihr dem Dateisystem den Feldtest in Community-Distributionen größtenteils erspart habt, der Euch sonst so gute Dienste leistet. Okay, Btrfs-Dateisysteme lassen sich bei Fedora und OpenSuse schon länger verwenden – aber als Standard-Dateisystem kommt es trotz einiger Anläufe bislang nicht zum Einsatz. Auch Ubuntu und andere Mainstream-Distributionen haben den Schritt bislang nicht gewagt. Daher haben bislang allenfalls jene Anwender Btrfs ausprobiert, die sich über das Dateisystem Gedanken machen und sich vom Stempel "experimentell" nicht abschrecken lassen, den das Dateisystem auch bei der derzeit aktuellen Vorabversion von Linux 3.3 noch trägt. Das dürfte nur ein kleiner Prozentsatz der Anwender gewesen sein. Und jene, die es wagten, finden durchaus noch Fehler, wie man in den Archiven der Mailingliste sehen kann, über die die Btrfs-Entwickler kommunizieren. So wurde beispielsweise erst Ende letzten Jahres mit Linux 3.2 ein Bug behoben, der bei Abstürzen oder Stromausfällen gelegentlich zu Dateisystemschäden führte.
Apropos Dateisystemschäden: Btrfs wurde immerhin schon hier und da in der Praxis erprobt – beim verbesserten und seit vielen Monaten versprochenen Werkzeug zum Prüfen und Reparieren von Btrfs-Laufwerken ist noch nicht mal das der Fall. Euer "verbessertes" Btrfsck, das Ihr jetzt ausliefert, ist bisher nicht einmal separat erhältlich. Euer Code dafür basiert offfenbar auf jenem, der sich in einem Git-Zweig des Quellcodes der Btrfs-Werkzeuge findet – und den alarmierenden Namen "dangerdonteveruse" ("Gefährlich; niemals verwenden") trägt.
Bei einer regulären Desktop-Anwendung könnte ich mich mit einem zu kurz gekommenen Feldtest vielleicht noch arrangieren. Aber bei einem Dateisystem, dem ich meine wertvollen Unternehmensdaten anvertraue, ist mir das selbst mit einer guten Backup-Strategie derzeit noch zu heikel – insbesondere, weil ich durch meine Recherche für das Kernel-Log immer mal wieder sehe, dass bei jeder neuen Kernel-Version noch einige Probleme korrigiert werden, die in Dateisystemen wie Ext3 und Ext4 schlummerten, die längst als stabil gelten. Jede Software hat halt Fehler, die gerade in neuem Code erst einmal gefunden und beseitigt werden wollen.
Und so richtig abgeschlossen ist die Arbeit an Btrfs auch noch nicht, denn es warten RAID-5-Support, Unterstützung für effizientere Kompressionsalgorithmen und noch einige weitere Verbesserungen auf die Integration. Solche Funktionen lassen sich auch später noch nachrüsten – ein paar weitere Optimierungen hätten dem Dateisystem aber vielleicht gut getan, denn bekanntermaßen ist es zum Beispiel nicht so gut zum Speichern von Datenträger-Images von virtuellen Maschinen geeignet. Auch als Datenbankspeicher taugt es vielfach weniger als Ext4 oder XFS. Daran ist die Verwendung von Copy-on-Write (COW) schuld, das viele der Vorteile von Btrfs erst ermöglicht. Es gibt durchaus Überlegungen, mit Tricks die prinzipbedingten Nachteile von COW zu umschiffen oder wenigstens deren Auswirkungen zu minimieren – vielleicht hättet Ihr darauf noch warten sollen.
Der mit den Updates für Eure Enterprise-Distributionen jetzt erst beginnende Feldtest wird zeigen, wie alltagstauglich Btrfs wirklich ist. Es würde mich nicht wundern, wenn der Ruf des "Next Generation File System" für Linux erheblich leidet, weil sich größere Probleme zeigen. Falls es viele Fehler sein sollten, muss das Dateisystem dann vielleicht sogar in eine weitere Entwicklungsrunde, bevor es die Linux-Welt dann als "Btrfs2" für sich erobern kann. (thl) (thl)
