Laut Aussage der btrfs-Entwickler soll das Dateisystem ja mittlerweile production-ready sein.
Dem gegenüber stehen neben eigenen Erfahrungen unzählige Berichte, in denen sich btrfs entweder bis zur Unbenutzbarkeit füllt, sowie entweder einzelne Daten oder gar das ganze Dateisystem schrottet.
Das unsägliche Problem des nötigen filesystem-rebalance (zu dem es lt. Aussage der Entwickler bisher kein Ansatz zur Lösung gibt) disqualifiziert btrfs für ein Produktionssystem bereits völlig neben dem Problem, dass man "btrfs filessystem df" nutzen muss, weil keine sinnvolle Meldung an das BS bzgl. des freien Speicherplatzes erfolgt. Außerdem kann es beim rebalance oder auch bei anderen Schreiboperationen zu einem kompletten zerlegen des Dateisystems kommen, wenn sich der Rechner dabei aufhängt oder einfach neu gestartet wird (reset, power-failure, etc.). Wie war das noch mal mit copy-on-write? Sollte ja irgendwie nicht passieren, oder?
Im Vergleich dazu waren selbst die frühen, sehr experimentellen Implementierungen von ZFS in FreeBSD völlig problemlos. Der gegenwärtige Stand von OpenZFS unter FreeBSD ist absolut rock solid (unter Solaris sowieso). Aufgrund eines Parity-Errors auf dem PCI-X-Bus hatte ich bei einem älteren Server immer wieder zu hard-locks des Systems bei hoher Last auf dem Bus. Und obwohl diese lockups immer wieder bei Schreiboperationen stattfanden, blieb das Dateisystem zu 100% konsistent und fehlerfrei (scrub ohne Fehler). Einzig die zu dem Zeitpunkt des crashes angelegte Datei wurde nicht zu Ende geschrieben, das wars. Ich gehe davon aus, dass selbst ZFS on Linux trotz des experimentellen Status deutlich zuverlässiger als btrfs ist. Dazu müsste ich allerdings mal paar tests durchführen.
Fazit für mich: Wem seine Daten lieb sind, macht einen ganz, ganz weiten Bogen um btrfs. Nutzt EXT4, XFS oder sonstwas, aber tut Euch btrfs nicht an.
Das Posting wurde vom Benutzer editiert (16.01.2015 14:13).