btrfs auf Produktivsystem

[tazinblack]

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!

[kernelOfTruth]

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/ ... 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

[kernelOfTruth]

Falls Interesse besteht:

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

https://github.com/kernelOfTruth/linux/ ... 14%2Bfixes


er enthält 8 zusätzliche Patches zu http://git.kernel.org/cgit/linux/kernel ... ntegration


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

[Klaus Meier]

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]

Falls Interesse besteht:

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

https://github.com/kernelOfTruth/linux/ ... 14%2Bfixes


er enthält 8 zusätzliche Patches zu http://git.kernel.org/cgit/linux/kernel ... ntegration


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

Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.

Kannst Du noch was zur Struktur sagen?
Hast Du Subvols und wenn ja für was?
Trennst Du zwischen System und Daten?

Was kernelOfTruth oben berichtet hat, klingt doch eher etwas unentspannt.
Manuell nachpatchen wollte ich eigentlich auch nicht.

[kernelOfTruth]

Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.

Kannst Du noch was zur Struktur sagen?

Bezüglich, wie ich das Dateisystem nutze ?

momentan auf 3 "Partitionen"

/ (system; lzo-Kompression - auf SSD)
/ (/usr/portage; lzo-Kompression - auf SSD)
/var/tmp (auf einem 8 GB zram-Laufwerk mit lz4-Kompression - Btrfs selbst läuft ohne Kompression)

Hast Du Subvols und wenn ja für was?

momentan noch nicht, aber wenn ich meinem Bauchgefühl trauen darf könnte ich diese bald für die System-Partition und /usr/portage einsetzen,

besonders Snapshots sind praktisch wenn ich mal wieder das System mit experimentellen/unstable Programmen aus Overlays z.B. Update

da sieht die Stabilität aber noch nicht so toll aus, wenn ich die Berichte in der Mailingliste richtig interpretiere

wie bereits geschrieben - bei manchen gibt es wohl gar keine Probleme - ergo "YMMV"

Trennst Du zwischen System und Daten?

Auf jedenfall !

Das System, /usr/portage, /var/tmp sind auf separaten (Btrfs) Partitionen, die Daten sind momentan noch ausschließlich auf ZFS


besonders weil ZFS wohl zu langsam auf der Systempartition und auch (relativ) schwierig zu konfigurieren ist [besonders im Single-Drive-Betrieb]

weiters traue ich Btrfs noch nicht vollständig (ENOSPC, Partition voll ohne die aller aktuellsten Patches (http://marc.info/?l=linux-btrfs&m=141178540704904)) - spontane Datenkorruption oder Verlust der Zugriffsmöglichkeit nach Absturz [gibt es aktuell bei ZFSonLinux aber als "Issue" auch]), setze ich es noch nicht in größerem Maße als Backup oder Datenplatte ein


Der aktuelle Stand ("integration" http://git.kernel.org/cgit/linux/kernel ... ntegration + Patches == https://github.com/kernelOfTruth/linux/ ... 09.2014_v2)

schaut schon ziemlich gut aus und mit den btrfs-progs 3.16.1 zeigt er sogar die Fehler im syslog bzw. dmesg - welche Dateien defekt sind:

Mal ein Beispiel:

btrfs scrub status /bak
scrub status for 8f518282-fea8-4bd1-ade9-20796f142684
scrub started at Fri Sep 26 18:32:09 2014 and was aborted after 1119 seconds
total bytes scrubbed: 115.93GiB with 206 errors
error details: verify=9 csum=197
corrected errors: 9, uncorrectable errors: 197, unverified errors: 0


[43163.689282] scrub_handle_errored_block: 7 callbacks suppressed
[43163.689289] BTRFS: checksum/header error at logical 21086208 on dev /dev/mapper/WD20EARS, sector 41184: metadata leaf (level 0) in tree 3
[43163.689290] BTRFS: checksum/header error at logical 21086208 on dev /dev/mapper/WD20EARS, sector 41184: metadata leaf (level 0) in tree 3
[43163.689292] btrfs_dev_stat_print_on_error: 7 callbacks suppressed
[43163.689293] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[43163.719712] BTRFS: fixed up error at logical 21086208 on dev /dev/mapper/WD20EARS
[43169.587212] BTRFS: checksum/header error at logical 634126336 on dev /dev/mapper/WD20EARS, sector 1254912: metadata leaf (level 0) in tree 7
[43169.587215] BTRFS: checksum/header error at logical 634126336 on dev /dev/mapper/WD20EARS, sector 1254912: metadata leaf (level 0) in tree 7
[43169.587217] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[43169.618124] BTRFS: fixed up error at logical 634126336 on dev /dev/mapper/WD20EARS
[43169.636874] BTRFS: checksum/header error at logical 634142720 on dev /dev/mapper/WD20EARS, sector 1254944: metadata leaf (level 0) in tree 7
[43169.636876] BTRFS: checksum/header error at logical 634142720 on dev /dev/mapper/WD20EARS, sector 1254944: metadata leaf (level 0) in tree 7
[43169.636878] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 3, gen 0
[43169.660588] BTRFS: fixed up error at logical 634142720 on dev /dev/mapper/WD20EARS
[43169.672894] BTRFS: checksum/header error at logical 634159104 on dev /dev/mapper/WD20EARS, sector 1254976: metadata leaf (level 0) in tree 7
[43169.672896] BTRFS: checksum/header error at logical 634159104 on dev /dev/mapper/WD20EARS, sector 1254976: metadata leaf (level 0) in tree 7
[43169.672898] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 4, gen 0
[43169.700981] BTRFS: checksum/header error at logical 634175488 on dev /dev/mapper/WD20EARS, sector 1255008: metadata leaf (level 0) in tree 7
[43169.700983] BTRFS: checksum/header error at logical 634175488 on dev /dev/mapper/WD20EARS, sector 1255008: metadata leaf (level 0) in tree 7
[43169.700986] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 5, gen 0
[43169.718411] BTRFS: fixed up error at logical 634159104 on dev /dev/mapper/WD20EARS
[43169.724950] BTRFS: fixed up error at logical 634175488 on dev /dev/mapper/WD20EARS
[43182.584496] BTRFS: checksum/header error at logical 1001586688 on dev /dev/mapper/WD20EARS, sector 4069760: metadata leaf (level 0) in tree 5
[43182.584500] BTRFS: checksum/header error at logical 1001586688 on dev /dev/mapper/WD20EARS, sector 4069760: metadata leaf (level 0) in tree 5
[43182.584503] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 6, gen 0
[43183.473031] BTRFS: fixed up error at logical 1001586688 on dev /dev/mapper/WD20EARS
[43183.482348] BTRFS: checksum/header error at logical 1001603072 on dev /dev/mapper/WD20EARS, sector 4069792: metadata leaf (level 0) in tree 7
[43183.482350] BTRFS: checksum/header error at logical 1001603072 on dev /dev/mapper/WD20EARS, sector 4069792: metadata leaf (level 0) in tree 7
[43183.482352] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 7, gen 0
[43183.483829] BTRFS: fixed up error at logical 1001603072 on dev /dev/mapper/WD20EARS
[43183.484247] BTRFS: checksum/header error at logical 1001619456 on dev /dev/mapper/WD20EARS, sector 4069824: metadata leaf (level 0) in tree 7
[43183.484248] BTRFS: checksum/header error at logical 1001619456 on dev /dev/mapper/WD20EARS, sector 4069824: metadata leaf (level 0) in tree 7
[43183.484250] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 8, gen 0
[43183.485222] BTRFS: fixed up error at logical 1001619456 on dev /dev/mapper/WD20EARS
[43183.485604] BTRFS: checksum/header error at logical 1001635840 on dev /dev/mapper/WD20EARS, sector 4069856: metadata leaf (level 0) in tree 7
[43183.485606] BTRFS: checksum/header error at logical 1001635840 on dev /dev/mapper/WD20EARS, sector 4069856: metadata leaf (level 0) in tree 7
[43183.485608] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 9, gen 0
[43183.486647] BTRFS: fixed up error at logical 1001635840 on dev /dev/mapper/WD20EARS
[43307.435028] BTRFS: checksum error at logical 14918418432 on dev /dev/mapper/WD20EARS, sector 31251072, root 5, inode 59217, offset 2859008, length 4096, links 1 (path: hdd2bak/mp3albs/own/Bravo Hits 26/_ Bravo Hits 26 (CD 1)/18-Plug'N'Play _ Warp '99.mp3)
[43307.435035] BTRFS: bdev /dev/mapper/WD20EARS errs: wr 0, rd 0, flush 0, corrupt 10, gen 0
[43307.435036] scrub_handle_errored_block: 7 callbacks suppressed
[43307.435037] BTRFS: unable to fixup (regular) error at logical 14918418432 on dev /dev/mapper/WD20EARS

bis vor ein paar Tagen hatte ich mich gewundert, warum er auf dieser gar nicht so alten Platte (2.5 Jahre alt) auf einmal Fehler anzeigt - Ende August war das ganze noch Fehlerfrei,

hatte davor aber schon manuell ca. knapp 10 Sektoren neu schreiben lassen (pending sectors) und extended offline S.M.A.R.T.

zeigte nichts mehr an

#19 Short offline Completed: read failure 10% 17128 3058543265
#20 Short offline Completed without error 00% 17119 -
#21 Short offline Completed: read failure 10% 17118 3058543264
2 of 2 failed self-tests are outdated by newer successful extended offline self-test # 4

Ich hab deshalb gestern abend mal ZFS drauf gemacht und startete ein zpool scrub - siehe da:

zpool status
pool: WD20EARS
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://zfsonlinux.org/msg/ZFS-8000-8A
scan: scrub in progress since Sat Sep 27 19:25:14 2014
438G scanned out of 912G at 65.8M/s, 2h3m to go
1K repaired, 48.03% done
config:

NAME STATE READ WRITE CKSUM
WD20EARS ONLINE 0 0 13
WD20EARS ONLINE 0 0 27 (repairing)

errors: 13 data errors, use '-v' for a list

es werden immer mehr Fehler und scrub läuft noch - der Platte ist also nicht mehr über den Weg zu trauen


Die Fehlermeldungen und Btrfs' Fähigkeiten scheinen durchaus (noch bzw. wieder) zuverlässig zu sein in Bezug auf Erkennung von defekter Hardware

Was kernelOfTruth oben berichtet hat, klingt doch eher etwas unentspannt.
Manuell nachpatchen wollte ich eigentlich auch nicht.

naja - das war es bis vor kurzem auch:

bis vor ein paar Tagen kamen auf einmal dutzende (und mehr) Fehler auf der System-Partition, die zwar erfolgreich behoben werden konnten

beunruhigt war ich dann aber schon


Formatierung und 3-4-fache Tests der SSD unter Windows brachten aber nichts zutage

Darum wieder ein stage4-Backup zurück und jetzt läuft es ohne Meldungen

dennoch merkwürdig - wird wohl durch die vielen aktuellen Patches verursacht worden sein

und es fanden sich höchstwahrscheinlich einige gröbere Probleme (Bugs seit es Btrfs gibt), Mängel bzw. effizientes Platzmanagement, etc. etc., die nun nicht mehr auftreten sollten

frisch formatiert + aktueller Kernel sollte einiges davon behoben sein


Na dann wirst du wohl oder übel bis mindestens 3.18 oder 3.19 warten müssen, dass es besonders in Bezug auf ENOSPC und Datenintegrität nach Abstürzen (Filipe Manana hat hier wirklich beeindruckende Arbeit geleistet) für den täglichen Einsatz geeignet ist - die notwendigen Änderungen sind im "Integration"-Zweig vorhanden, der frühestens in 3.18 drin sein wird

besonders
Btrfs: remove empty block groups automatically
(ENOSPC)

und diverse patches bezüglich
data corruption, fsync, etc.

werden wohl erst da standardmäßig in Btrfs enthalten sein, ein Teil wird mit Sicherheit zurückportiert

[tazinblack]

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.

Kannst Du noch was zu der verwendeten Struktur/Subvols sagen?

[Klaus Meier]

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]

Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.

...

Wenn ich auch bisher nur gute Erfahrungen damit gemacht hab, habe ich ich jetzt vorerst mal doch noch für ext4 entschieden. Btrfs ist mir momentan doch noch nicht stable genug.

So hab ich dann immer noch die Möglichkeit das Ganze nach btrfs zu konvertieren.

Danke für die Tipps!

[Klaus Meier]

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]

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.

Ich denke das ist kein Feature sondern ein Bug...
Ich hatte in der Vergangenheit auch den ein oder anderen Schreckensmoment und hab mir angewöhnt bis mindestens 3.xx.3 zu warten. Da sollten die gröbsten Schnitzer ausgebügelt sein.

[kernelOfTruth]

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.

Ich denke das ist kein Feature sondern ein Bug...
Ich hatte in der Vergangenheit auch den ein oder anderen Schreckensmoment und hab mir angewöhnt bis mindestens 3.xx.3 zu warten. Da sollten die gröbsten Schnitzer ausgebügelt sein.

mindestens !

Wenn ich mir die aktuellen Geschichten mit Reiserfs, RCU stalls, etc. mit 3.17 anschaue dauert es wirklich mindestens so lange, bis die wichtigsten Funktionen getestet und die gröbsten Schnitzer raus sind

Mehr Tester braucht der Kernel


Ein Heads-Up:

zur Zeit gibt es wohl Dateisystem-Korruption mit Snapshots und 3.17.x

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

[schmidicom]

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(8) 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]

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]

@kolibri Danke für den Erfahrungsbericht, sehr interessant