Skip to content

Meine persönliche Erfahrung mit BTRFS

Ich plaudere 'mal aus dem persönlichen Nähkästchen.

Ich hatte eine ganze Zeit lang einen persönlichen Server mit BTRFS am Laufen. Weniger wegen RAID, mehr wegen Snapshots.

Bislang fand ich BTRFS "schick": Es ist im Kernel, einfach zu benutzen, die "normalen" Tools zum Anlegen und Verwalten sind intuitiv.

Bislang.

Was meinen Eindruck - gelinde gesagt - geändert hat, ist das Verhalten von BTRFS im Desaster-Fall. Es gibt ja diverse Anleitungen, Howtos etc. (siehe z.B. hier). Aber sind wir mal ehrlich: Das ist gefühlt alles mehr Glückssache als etwas Handfestes.

Ich weiß, dass es keine eierlegende Wollmilchsau bei den Dateisystemen gibt, aber ein einfaches "btrfs-check-and-repair" wäre sinnvoll. Im Endeffekt interessiert es mich - auch als sagen wir mal technisch versierten :-) - Nutzer nicht, wie ein Tool das macht. Als Technie mit Programmierergenen wünsche ich mir ein "mach halt", das alles tut, was automatisch möglich ist.

Um es nochmal genauso ehrlich zu sagen: Fast kein Anwender wird irgendwelche "manuellen" Entscheidungen treffen wollen, oder gar im Dateisystem rumspielen. Es ist mir lieber, wenn 90%+x wiederhergestellt werden, aber das zeitnah, und ich den Rest aus einem Backup wiederherstellt, als dass ein Tool versucht, 100% zu erreichen - es aber nie schafft.

Ich bin daher zu ZFS gewechselt. Ich bin gespannt, wie sich das schlagen wird :-)

Das gilt im Übrigen auch für alle manitu-eigenen Systeme. Das war vor ein paar Tagen eine "Anweisung von oben" von mir an die Technik. Die Migration läuft bereits.

Good bye, BTRFS.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

id

Hey Manuel,

geht es dabei um die Mountpoint-Bereiche auf welche "Kunden/SQL/Daten" gespeichert werden? Oder geht es auch um den /-Mountpont?
Denn ich finde persönlich ext4 immer noch sehr angenehmen ans /-Mountpoint zu verwenden. Alles andere finde ich eher Spielerei.

VG
id

Andreas

Same here. Ich habe den Fehler gemacht BTRFS das RAID verwalten zu lassen. Als es sich dann in den readonly Modus geschalten hat weil eine Festplatte abgeraucht ist habe ich den zweiten Fehler gemacht und nicht sofort alle Daten auf einen weiteren Datenträger kopiert (wegen Platzmangel) und das System rebootet und eine neue Platte eingebaut.

Nach dem Neustart hatte ich keine Chance mehr an meine Daten ran zu kommen - die neue Platte hat das RAID nicht akzeptiert und im degraded Modus lies es sich nicht mehr mounten. Alle Anleitungen scheiterten an Fehlermeldungen bei denen mir niemand helfen konnte.

Ich musste meine Daten aus der Cloud wiederherstellen - was bei 1TB dann entsprechend lange gedauert hat.

Jetzt nutze ich wieder ext4 und mache meine Snapshots mit restic auf das lokale Backup Medium. Live Zugriff auf Snapshots benötige ich nicht.

Sebastian

ext4 ist allerdings auch nicht so zuverlässig, wie man es vielleicht glauben mag. Mir hat es erst vor kurzem in einer VM das ext4-Dateisystem zerschossen. Sämtliche Versuche, es zu reparieren, sind gescheitert, bei einigen Dateien gab es auch nach einem fsck immer wieder Fehler.

Ich habe das Problem dann gelöst, indem ich der VM ein neues Festplatten-Image spendiert und alles aus einem Backup wiederhergestellt habe (OK, ich habe ein paar Dateien, die sich seit dem Backup geändert hatten und die sich noch lesen liesen, hinüberkopiert).

DigiTalk

Ich habe hier bei einem NAS auf Basis eines PCs seit etlichen Jahren ZFS unter FreeBSD (genauer: XigmaNAS) im Einsatz mit 8 Platten und doppelter Redundanz.
Der Austausch einer Platte gelingt problemlos mit minimaler downtime (beim Einbau wegen keinem Hotplug). Die Wiederherstellung läuft prima im Hintergrund.

Sven

btrfs ist effektiv in dem Moment ganz tot gewesen, als RedHat es lieber aus RHEL entfernt hat, anstelle es weiterzuentwickeln bzw. darauf zu warten.

Wenn doch nur irgendwer anders als ausgerechnet Oracle Sun gekauft hätte, wäre möglicherweise ZFS längst passend lizensiert im Mainline-Kernel zu finden ...

Manni

Der Artikel wirft Fragen auf.
Du wechselst von btrfs zu ZFS, Hauptleitsatz "zu kompliziert" im Disaster-Fall; orderst dann gleich noch die Mitarbeiter an, alle Manitu-Systeme umzustellen.
Warum geht man nun von einem Neben-FS zum nächsten Neben-FS?
Gibt es objektive Gründe, die gegen das Linux-Standardfilesystem ext4 sprechen?
Warum fällt dir das eigentlich erst jetzt auf - gab es also bei euch noch nie diesen "Recovery-Fall", den du privat erlebst? Fast schwer zu glauben... :-)

Martin E.

Ich hatte in der Zeit als Manitu-Kunde aufgrund vieler Dinge immer das Gefühl es mit einem Hobby-Hoster zu tun zu haben, was mich dann auch zur Kündigung veranlasst hat. Das von Manuel angewiesene Vorgehen bestätigt mich da in meiner Meinung.

Fabian

Ja, ganz schlimm diese leidenschaftlichen Hoster, die Spaß an der IT haben und ständig jenseits des Mainstreams nach besseren Lösungen schauen. Besonders als Webspace Kunde, wo es nur darum geht, dass die WebApplications laufen ohne das man das System dahinter administrieren muss.

Martin E.

"Spaß an der IT" und "Leidenschaft" schließt Professionalität ja nicht aus. Bei Manitu hatte ich eben nicht das Gefühl, dass diese gegeben ist. Aber das ist vielleichtoll auch nur meine Meinung.

Dave

Richtig, die Hoster, die ihre Hard- und Software ständig aktualisieren, nach Verbesserungen suchen und dazu andauernd irgendwelche Kundenmaske anwenderfreundlicher & komfortabler gestalten, sind wirklich eine Pest.
Mit diesen neumodischen E-Mails kann ich mich auch immer noch nicht anfreunden, meine Steintafeln sind absolut witterungsbeständig und somit vor Datenverlust gesichert.

Manni

Hm, wäre ja schön, wenn es mal großartige Neuerungen geben würde? Ich sehe eher ein fast schon pedantisches, unnötiges Perfektionieren von Nebensächlichkeiten.

Warum renoviert man z. B. nicht mal die Produktpalette der dedizierten Server? Für 40 EUR gibts Uralthardware, für 60 und 80 EUR ist die Hardware ebenfalls über 7 Jahre alt. Ist das kein Thema? Warum steigt man z. B. nicht in den vServer-Markt ein?

Ich habe wirklich Respekt, dass Manitu in der Form überlebensfähig ist. Das ist wirklich ernst gemeint!

Robert

Ich bin bzgl. der Dateisysteme abseits vom Mainstream auch vorsichtig. Ein guter Indikator für mich ist Debian. Wenn die ein Dateisystem als Standard definieren, dann ist es auch stabil.
Btrfs nutze ich derzeit nur für Backup-Server, da man sehr bequem Platten tauschen kann und auch mit ungerader Plattenzahl Redundanz bekommt. Jedoch auf den produktiven Maschinen läuft ext4.
ZFS hat unter Linux ja auch einen schweren Stand...

Viele Grüße

Meddl

Vergesst BTRFS, ext4 und so weiter. Das beste Dateisystem ist mit Abstand ASB8.

Herbert Eisenbeiß

Vergesst Btrfs - das Ding ist die ewige Hoffnung auf einen schlechten ZFS-Klon im Linux-Kernel, und selbst nach über zehn Jahren Entwicklung in wesentlichen Bereichen noch immer Baustelle und/oder instabil.

Raid 5/6 geht nach wie vor nicht, es kann nach wie vor keine Triple Parity, es ist vor allem bei Datenbanken und VM-Images so verdammt langsam, dass die Autoren des Abschalten von COW für solche Dateien empfehlen (dann kann man auch gleich zu Ext4/XFS greifen!) und wenn es abschmiert, dann aber auch richtig. Dann ist man erst einmal stundenlang damit beschäftigt, irgendwelche obskuren Anleitungen aus Timbuktu zu finden, mit denen man es vielleicht wieder zur Arbeit überreden könnte. Nein Danke!

Btrfs ist das neue Reiser4 - es ist zwar im Kernel da, aber gescheitert. Niemand glaubt noch wirklich daran, dass aus diesem Eiterpickel in diesem Leben noch ein halbwegs brauchbares Dateisystem werden wird, und erst recht nicht mehr das neue Standarddateisystem von Linux!

Oracle hat neulich Dtrace still unter die GPL gestellt. Das war eine der Technikglanzleistungen von Sun, die zeitgleich zu ZFS eingeführt wurden. Wer weiß, vielleicht bereitet Oracle auch schon längst die GPL-Lizenz für ZFS vor. ZFS hat zwar auch seine Eigenheiten und Problemchen, ist im Gegensatz zu Btrfs aber schon seit 13 Jahren im Produktivbetrieb.

Und wer es lieber alternativ mag, der schaut sich Bcachefs von Kent Overstreet an. Dem Mann hat es einfach so sehr gestunken, dass es kein vernünftiges COW-Dateisystem für Linux gibt, also hat er sich aufgerafft und entwickelt eben selbst eines. Aktuell arbeitet er an der Aufnahme im Kernel.

https://bcachefs.org/

T

Wobei ich da Sätze wie:

"Scalable - has been tested to 50+ TB, will eventually scale far higher"

gruselig finde. ZFS kann das definitiv. Kenne Installationen mit mehreren Hundert TB bestehends aus über 120 Platten.

Randalf

Ich habe btrfs auf mehreren Systemen im Einsatz, vor allem wegen der Snapshot-Funktion. Desasters habe ich aber auch schon erlebt...

Ich habe einen Wechsel auf ZFS in Erwägung gezogen, aber soweit ich das verstehe, sind die Snapshots dort vom Dateisystem unabhängig und können nicht wie bei btrfs als eigenständige Verzeichnisse gemounted werden, richtig?

Christian Kühnke

@Randalf: Snapshots können entweder "visible" sein, dann liegen Sie aufgelistet und traversierbar unter "$mountpoint/.zfs/snapshots" oder man fertigt z.B. einen Klon an (zfs clone) und mounted diesen auf einem beliebigen Mountpoint.

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen