btrfs auf Produktivsystem

tazinblack · Posted: Sun Sep 14, 2014 7:19 pm Post subject: btrfs auf Produktivsystem

Hallo zusammen,

ich will mir die Tage ein neues System aufsetzen und frage mich welches FS ich nehmen soll.
Auf meinem Notebook habe ich schon seit 9 Monaten btrfs auf ner SSD und bin zufrieden.
Allerdings nutze ich dort auch keine besonderen Features.

Inzwischen soll ja das "disk format" stable sein.

Die neue Kiste soll Mail- und Webserver werden. Zwar nur für den privaten Gebrauch, aber wer
verliert schon gerne seine Mails, etc.

Interessant finde ich generell Snapshots und Kompression mit lzo, Deduplizierung.

Z.B. könnte ich mir vorstellen, den Bereich in dem Mails liegen zu komprimieren.

Grundsätzlich würde ich trennen wollen zwischen System und Nutzdaten.
Also z.B. nach fehlerhaften Systemupdates wieder auf den Snapshot vorher zurück zu können, ohne dabei
z.B. in der Zwischenzeit eingegangene Mails zu verlieren.

Leider finde ich die ganze Bedienmechanik doch recht komplex.
Vielleicht liegts auch dran, dass ich damit (noch) nicht so vertraut bin.

Gibts da bei Euch erste Erfahrungen?

Danke im Voraus für die Tipps!
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes

kernelOfTruth · Posted: Sun Sep 14, 2014 9:18 pm Post subject:

Btrfs läuft hier auf /usr/portage & / (system root)

der Rest auf ZFS

Infos:

Snapshots, Senden:
http://marc.info/?l=linux-btrfs&m=140974713506816
http://marc.info/?l=linux-btrfs&m=141014110627013

Subvolumes:
http://marc.info/?l=linux-btrfs&m=141038814918997

Datenverlust nach Crash:
http://marc.info/?l=linux-btrfs&m=140872365809680

OOM bei Scrub, normaler Nutzung, etc.:
konnte bis jetzt nur stärkeren RAM-Verbrauch als ZFS feststellen

ENOSPC:
http://marc.info/?l=linux-btrfs&m=141027296608438

Kompression, rsync:
http://marc.info/?l=linux-btrfs&m=140957843615564

Btrfs unterstützt bis jetzt nur gzip & lzo
mit beiden gibt es die genannten timeouts (ohne wohl nicht), gzip komprimiert nicht besonders effizient: damit sind manche Dateien größer also original - mit mit lz4 & ZFS keine vergleichbaren Beobachtungen
lz4 ist momentan keine Priorität für Btrfs

Deduplizierung:
lief unter ZFS recht langsam (auf früherem Rechner), mittlerweile gibt es AVX-Beschleunigung für Prüfsummen als Pull auf github (https://github.com/zfsonlinux/zfs/pull/2351)
damit sollte es mit aktuellen Prozessoren performanter laufen

ich nutze unter ZFS Ditto Blocks:
https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection
das sind im Endeffekt zusätzliche/separate Volumes unter dem Root vdev und den Subvolumes vergleichbar

Btrfs-Nutzung & Stabilität:
Hier im Forum, Phoronix und anderswo gibt es auch äußerst positive Berichte über Nutzer von Btrfs die z.B. mit tausenden Btrfs Snapshots arbeiten und bis jetzt noch keine Problem damit hatten.
Versuchen schadet nichts - wenn es nicht gehen sollte, gibt es immerhin ZFS mit dem eine vergleichbare Funktionalität gegeben ist

Regelmäßige Backups auf andere Dateisysteme sind Pflicht
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004

kernelOfTruth · Posted: Mon Sep 15, 2014 1:23 am Post subject:

Falls Interesse besteht:

in meinem Repo auf github ist der neuste Integration-Ast mit einem Fix (https://github.com/kernelOfTruth/linux/commit/793acd97e3f15b283bffa4f448f157d294be756c), der das ENOSPC-Problem beheben soll

https://github.com/kernelOfTruth/linux/commits/btrfs-integration_13.09.2014%2Bfixes

er enthält 8 zusätzliche Patches zu http://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=integration

einen darauf basierenden Kernel setze ich zur Zeit hier ein,

damit sollten wirklich die allergröbsten Fehler - auch in Verbindung mit Daten-Korruption beim nicht-sauberen Herunterfahren (Reset, Hardlock, etc.) - hoffentlich behoben sein
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Ich nutze schon seit einiger Zeit btrfs und bin begeistert. Zum einen ist es extrem robust bei einem Crash. Habe hier so ein Laptop, welches im Sommer gerne mal wegen Überhitzung einfach abschaltet. Nein, es taktet nicht runter, was man ja machen könnte. Dank cow hatte man dann in einigen Fällen nur die letzte Version einer Datei. Aber die war immer zu 100% in Ordnung. Bei einem anderen FS wäre es schon möglich, dass die Datei einfach defekt ist.

Datenverlust habe ich noch keinen gehabt. Ich lege jeden Tag als erstes einen Snapshot vom System an und dann kann man eigentlich tun und lassen was man will. Es ist ja immer die alte Version einer Datei vorhanden. Ich denke mal, ein Datenverlust durch Fehlbedienung ist deutlich häufiger als durch einen FS-Crash.

Ich kann es nur empfehlen.

tazinblack · Posted: Mon Sep 22, 2014 3:16 pm Post subject:

kernelOfTruth · Posted: Sat Sep 27, 2014 7:34 pm Post subject:

tazinblack · Posted: Sun Sep 28, 2014 8:18 am Post subject:

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Ich habe eine Partition, auf der mein System ist. Komplett. Und dann noch ein eine andere, auf der ich etwas zum Spielen habe. Oder als Rettungssystem, wenn das erste nicht mehr will. Ok, ist nicht optimal, aber mein Rechner hat gerade die Grätsche gemacht und ich bin hier erst mal an einem Notsystem. Eine perfekte Lösung ist in Arbeit...

Ich benutze ansonsten nur Snapshots. Mache ich jeden Morgen als erstes, wenn ich die Kiste einschalte. Das ist alles. Kannst du dich mit deinem System austoben und tun und lassen, was du willst. Passiert ja oft mal, dass man aus Versehen etwas löscht oder kaputt editiert. Dann holst du dir die alte Version aus dem Snapshot wieder. Und wenn du dir dein ganzes System geschrottet hast, dann boote ich das andere System, lösche alles bis auf /home und kopiere mir das lauffähige System aus dem Snapshot wieder zurück.

Bin jetzt seit Februar 2013 auf Btrfs. Und wenn es demnächst noch besser wird, dann sage ich nicht nein.

tazinblack · Posted: Sun Sep 28, 2014 7:04 pm Post subject:

[quote="kernelOfTruth"]

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Na prima, das ist jetzt so etwas wie der Gau. So wie es aussieht, gehen seit Kernel 3.17 keine Snapshots mehr. Man kann sie anlegen, aber dann nicht mehr drauf zurückgreifen und sie auch nicht mehr löschen. Die Daten sind aber weiterhin in Ordnung.

franzf · Advocate Joined: 29 Mar 2005 Posts: 4565

kernelOfTruth · Posted: Tue Oct 14, 2014 2:20 pm Post subject:

schmidicom · Veteran Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz

Sorry für die Nekromantie bei diesem Thema (falls das unerwünscht ist) aber wie sieht es eurer Meinung nach bei btrfs heutzutage aus?

Ich spiele seit einiger zeit mit dem Gedanken btrfs eine weitere Chance zu geben.
Grund dafür ist unter anderem halt das es bei XFS, trotz seiner hohen Stabilität (ist mir noch nie gecrasht), einige Dinge gibt die einem auf den Zeiger gehen können. Zum Beispiel sind die dazugehörenden Userspace-Tools halt alles andere als "schön gemacht", sie sind sogar so speziell das SYSTEMD-FSCK@.SERVICE(

jedes mal beim Versuch eine Dateisystemprüfung durchzuführen kläglich scheitert. Und auch die schon seit gefühlt einer Ewigkeit angekündigten Features wie Snapshots und ein standardmäßig aktiviertes CopyOnWrite lassen ziemlich lange auf sich warten.

mike155 · Posted: Mon Jan 10, 2022 6:01 pm Post subject:

Ich würde ja gerne etwas zu Btrfs schreiben - aber da ich nur ext4 verwende, kann ich nicht mitreden.

Warum ich nur ext4 verwende? Für mich zählt bei Dateisystemen nur eines: dass sie meine Daten nicht zerstören. ext4 verwende ich seit über 10 Jahren. Auf einer ganzen Reihe von Systemen. Ich hatte noch NIE Probleme mit ext4 und ich habe noch NIE Daten durch ext4 verloren.

Warum sollte ich also jemals wieder etwas anderes wollen als ext4?

kolibri

Also ich nutze btrfs seit es damals im staging Bereich des Kernels gelandet ist und habe meine Höhen und Tiefen damit erlebt.

tl;dr: Ich liebe es mehr als ich es hasse

Kurze Einleitung fürs Verständnis: Ich nutze es nicht nur aufm Desktop/Laptop für alle Partitionen, sondern auch aufm Root-Server wie auch auf dem produktiven Fileserver eines Kunden. Die meiste Erfahrung erlangte ich dabei auch mit dem Kunden-Server.

Dieser besagte Server war ein Dual-Sockel Xeon, mit 32 GB RAM und 8x 3 TB WD Black HDDs. Anfangs bestand die Datenpartition aus einem mdraid mit raid10 über alle 8 Platten und ext4 obendrauf. Soweit, so stabil.

Als dann mehrfach vom Kunden der Wunsch kam, dass sie gerne regelmäßig auch nochmal auf einfach Art in den Backups der letzten Tage rumstöbern möchten, habe ich die Gelegenheit genutzt, die Datenpartition auf btrfs zu migrieren. Aber nicht mit btrfs-convert, das habe ich nie ausprobiert. Stattdessen das ext4 geshrinkt, ein paar Platten aus dem mdraid entfernt, diese dann zu einem btrfs mit raid1 (meta und data) formatiert und dann die Daten ge-rsync'd.
Anschließend dann das ext4/mdraid komplett weggeworfen und die Platten dem btrfs hinzugefügt, geht ja super einfach im Live-Betrieb. Das ist auch eins meiner liebsten Features an btrfs, dass man während des Betriebs das gemountete Dateisystem einfach vergrößern und verkleinern kann, Devices rausnehmen oder hinzufügen usw.

Nachdem alle Platten im btrfs waren, natürlich einmal ein balance angestoßen, um die Daten auf alle Platten zu verteilen. Die Daten des Kunden landeten alle in einem subvolume, von dem täglich ein read-only Snapshot erstellt wurde, die dann über Samba auch einsehbar waren. Kunde ist erstmal zufrieden.

So wuchs dann langsam die Datenmenge auf dem Server an, dass die Kapazität langsam gen 80% wanderte. Kunde wollte aber kein Geld investieren, also brachte ich den Vorschlag, dass ich auf raid5 oder raid6 umstellen kann, es aber ein bisschen risky ist. Kunde einverstanden, so habe ich das btrfs auf raid6 (data) konvertiert, natürlich auch im laufenden Betrieb, ohne Vorkommnisse. metadata blieb auf raid1. Und ja, zu der Zeit war raid56 noch mit dicker roter Meldung als experimentell markiert.

Da die Daten zum größten Teil aus Photoshop und Illustrator Dateien bestand, habe ich ebenfalls die zlib Kompression eingestellt, mit höchster Kompressionsstufe. Aber mit verzögerter Kompression (mount mit compress, im FS aber kein compress "prop"), also erstmal wurden die Daten unkomprimiert abgelegt und ich habe dann per Cronjob alle Dateien, die X Tage nicht mehr angefasst wurden, mit btrfs "defragmentiert" und dabei die zlib Kompression erzwungen. Anschließend noch duperemove drüber, da wurde dann schon spürbar Platz eingespart.

Es kam zu einem Stromausfall mit Spannungsstoß, der auch die USV gekillt hat: btrfs raid6 läuft ohne Fehler.
Hier und da verabschiedet sich mal eine Festplatte und wird durch eine neue ersetzt: btrfs raid6 läuft ohne Fehler.
Aber dann fiel mal wieder eine Platte aus, aber nur so halb. Sie flappte quasi. Das hat das btrfs raid6 schon ins Straucheln gebracht. Es war aber keine Ersatzplatte vorrätig (obwohl ich dazu geraten hatte), so vergingen ein paar Tage in diesem Zustand. Als dann noch zufällig irgendein Humanoid im Serverraum Dinge getan hat, wurde irgendwie ein Reset am Server ausgelöst. Das war dann das Todesurteil.

Instinktiv würde man ja ein fsck machen, aber davon wird bei btrfs abgeraten. Ich konnte das Filesystem noch als degraded mounten, aber nur read-only. Und beim Zugriff auf die meisten Dateien gab's dann wildeste Exceptions und keine brauchbaren Inhalte. Der beste Weg wäre dort eigentlich ein btrfs scrub, da btrfs beim Lesen der Daten feststellt, dass sie kaputt sind und sie dann entsprechend herstellen würde, allerdings war das btrfs scrub zu der Zeit irgendwie buggy. Also in meinem Fall hat es beim ersten Fehler, der dann auftrat, zu einer Kernel panic geführt. Ich habe dann auch mal ein paar ältere btrfs-progs Versionen und auch Kernel ausprobiert, Gentoo macht's ja zum Glück sehr einfach, aber auch dort hatte ich keinen Erfolg. Step 2 ist dann mit btrfs-check rumzuprobieren, aber auch das brachte keine Besserung. So blieb mir am Ende nur der radikale Schritt: neu formatieren und Backup restoren. An dem Tag habe ich mehr geschwitzt als ich trinken konnte.

Kunde war mäßig begeistert, denn das Restore hat einige Tage gedauert, bis es abgeschlossen war. Aber auch nur, weil ich auf das remote Backup über deren Krüppel-Leitung zugreifen musste, da das inhouse Backup, wofür der Kunde selbst zuständig ist, über 1 Jahr alt war. Seitdem hat der Kunde sich aber etwas engagierter ums inhouse-Backup gekümmert.

Im Laufe der Zeit kam dann ja zstd in btrfs mit rein, worüber ich mich sehr freute. Damit konnte ich die "alten" Daten nochmal viel effektiver komprimieren und wieder etliche GB freimachen.

Mit einem späteren Kernel kamen dann ja auch noch die Modi raid1c3 und raid1c4 hinzu, welche ich dann sofort für metadata aktivierte. Ich habe dann, auf meinem privaten Virtualisierer auch einen Test gemacht:
VM mit 4 HDDs (je 200 GB), btrfs mit raid1c4 (metadata) und raid5 (data). Das FS dann zu grob 60% mit Zufallsdaten gefüllt, Prüfsummen der Daten gezogen. Dann im laufenden Betrieb eine der Platten gewaltsam ausgehängt und weitere 30% mit Zufallsdaten gefüllt. Dabei dann spontan die VM abgeschossen. Snapshot der VM gemacht und gebootet. Btrfs lief noch super, halt nur degraded. Neue "Platte" hinzugefügt, re-balance, alles super. VM nochmal beendet, Snapshot wiederhergestellt und die vorher getrennte Platte wieder eingehangen, dann gebootet. btrfs lief direkt "normal", ohne degraded. Aber richtig sauber war's ja nicht. Ein btrfs scrub hat dann Warnungen gegeben, aber mit dem Hinweis, dass die Daten erfolgreich korrigiert werden konnte. Ein re-balance hat dann dafür gesorgt, dass alle Daten wieder gleichmäßig verteilt sind.

Ein anderer Test mit gleicher Konfiguration bestand dann daraus, im laufenden Schreibprozess die VM abzuschießen, und dann auf jeder "HDD" zufällig 2 GB am Stück zu überschreiben, aber nicht alle an der gleichen Stelle. Die VM dann gebootet und ein btrfs-scrub hat alle Fehler korrigiert.

Fazit: Mittlerweile kann man btrfs ziemlich sicher einsetzen, auch raid5/6 für data, solange man metadata auf mindestens raid1 und niemals raid5/6 setzt, besser aber raid1c3 oder raid1c4. Im Fehlerfall niemals fsck machen, damit richtet man nur noch mehr Schaden an. Erst btrfs-scrub probieren, dann btrfs-check. Wenn das nix hilft und die Verzweiflung groß genug ist, kann man als letzten Strohhalm noch fsck probieren. In jedem Fall aber: ein Backup ist durch nix zu ersetzen, außer durch noch mehr Backups.

PS: btrfs-quota habe ich bisher noch nicht groß genutzt

forrestfunk81 · Guru Joined: 07 Feb 2006 Posts: 565 Location: münchen.de

@kolibri Danke für den Erfahrungsbericht, sehr interessant
_________________
# cd /pub/
# more beer