DS420+ mit 4x6 TB und SHR2 (Raid 6) + Btrfs als Paritätsschutz vor Bitfäule? (Paritätscopy App)

[synfor]

In der DS420+ bringt SHR2 keine Vorteile. Hint: Die hat nur 4 Bays und sowohl bei RAID6, als auch bei SHR2 müssten alle 4 Platten getauscht werden, um mehr Speicherplatz zu bekommen.

Ach ja, die RAID-Gruppen der ganz großen Synology Kisten dürften nach dem gleichen Prinzip wie SHR(2) funktionieren, denn ich wüsste sonst nämlich nur einen anderen Weg einen Speicherpool aus mehreren RAIDs aufzubauen: die RAIDs zu kaskadieren wie bei RAID10 oder RAID01.

 

[nas-central.de]

SHR ist proprietärer Consumer Kram um Heimanwendern die Entscheidung abzunehmen, welcher Raid Level der Beste für die jeweilige Bestückung ist. Das wird im Enterprise Bereich niemand anrühren. Die Arrays werden bei einer Raid-Gruppe über den Logical Volume Manager zu einem Pool zusammen gefasst.

 

[DS214x20220109]

Man kann sich auch mehr Aufwand machen als man nutzen daraus hat. Beim Einsatz von Festplatten mit 10 hoch 15 oder höherer Bitfehlerwahrscheinlichkeit + einem BTRFS Raid6 inkl. Prüfsummen + Scubbing + regelmäßigen Backups ist Bit Rod nahezu ausgeschlossen und für den normalen Benutzer und die meisten KMUs nicht relevant.

Da fällt mir gerade dieses Zitat hier ein:

Synology hat uns nun bestätigt, dass die DS716+ keine bitrot-correction unterstützt, sondern lediglich Fehler feststellt und meldet. Dies ist nun auch im Artikel entsprechend vermerkt. Eine automatische Korrektur findet somit nicht statt. Laut Synology sei der Schutz zu ineffizient und benötige zu viel Speicherplatz, weshalb an einer eigenen Lösung gearbeitet werde.

Siehe CB Forum: Synology DS716+ im Test: Mit Prüfsummen und Snapshots gegen Datenverlust #119

Okay, das war von 2016
Hoffe das es bei der DS420+ im Jahr 2022 besser aussieht..

Ich versuche es langsam zu bereifen nur mir fällt das ganze Thema mit Bit-Rot / Bit-Flips echt schwer

Was ich schon mal verstanden habe:

SHR2 oder Raid 6 sind komplett unabhängig vom Dateisystem (Egal ob EXT4 oder BTRFS)

BTRFS sieht den Pool als Einzel Festplatte an obwohl 4 HDDs am Stück im Raid 6 oder SHR2 zusammen laufen?

Aber Raid 6 oder SHR2 haben doch genug Paritätsinformationen um bei einem Ausfall von 2 Festplatten
die Daten trotzdem wiederherzustellen?

Wenn jetzt z.B. auf einer von den 4 Festplatten Bitfäule auftritt, dann liegt es doch daran das die eine Festplatte nicht mehr in Ordnung ist
und das man sie tauschen sollte? Das sieht man ja an den SMART Werten, falls sie nicht sofort den Geist aufgibt..

Wird die Bit-Rot Korrektur gar nicht unterstützt weder vom Raid 6 bzw. SHR2 ?

Das eingesetzte BTRFS Filesystem über mdadm? von Synology,
kann nur Bit-Rots erkennen und nur eine Fehlermeldung ausgeben?

Bei nicht ECC RAM würde es die Daten kaputt-korrigieren, so wie das verstanden und gelesen habe..
Darum kann die DS im DSM nur Bit-Rots erkennen und Fehlermeldungen ausgeben.

Ich habe privat seit mehr 20 Jahren Server mit mind. 5 Festplatten im Raid6. Habe noch nie z.B. Dateien nicht mehr öffnen können oder Fehler in Bilder oder Videos gehabt. Und selbst wenn ein Bit kippt wird man das fast nie merken (kann ein Pixelfehler in einem Foto sein, oder in einem Videobild). Und selbst wenn noch etwas auftritt, bei momentan knapp 20TB Tendenz steigend wäre ein defekter Pixel oder gar jpg nicht relevant.

Zitat aus dem CB Forum / Beitrag: Synology DS716+ im Test: Mit Prüfsummen und Snapshots gegen Datenverlust #9

Das gibt es schon immer.. ist aber erst vor ein paar Jahren wirklich aufgefallen als die Datenberge immer größer wurden... ALLE Daten altern und gehen dabei kaputt. Es sei denn du verwendest ECC RAM + btrfs/zfs oder eben MDiscs.

Dann geht es dort weiter mit Studien über CERN + Kosmische Strahlung + Multibit Fehler + ZFS ist besser
+ Consumer Hardware wäre viel zu billg und warum kostet ECC das dreifache
und Unternehmen zahlen halt für Datensicherheit einen hohen Preis.
Dann geht es dort weiter mit Ford Nox, USV, Strahlengeschützte Server Räume und weiss was alles an Schutzmaßnahmen.

Nach dem ich alle Foren Einträge gerade gelesen habe, bin ich schon wieder verunsichert!

Ich würde dir zu einem normalen Raid 6 raten.

Hat das normale Raid 6 im DSM dieses mdadm ?

Das SHR2 bringt dir nur was, wenn du Festplatten mit unterschiedlicher Größe zusammenwürfeln willst.

Oder wenn man später doch noch auf größere Festplatten umziehen möchte?

Dementsprechend trifft man es auch nur im Consumer-Bereich an oder bei Firmen, die nicht wissen was sie tun.

Passend dazu fällt mir gerade dieses Zitat hier aus dem CB Forum ein, was ich vor ein paar Wochen gelesen habe

nur als Joke am Rande, was ich in einer Firma gesehen habe: da war eine 500GB HDD verbaut, die nur eine 200GB Partition hatte, die langsam voll war. Beim Erstellen einer weiteren Partition hat sich heraus gestellt, dass die Platte knapp "oberhalb" der 200GB Marke massive Fehler hatte und vermutlich deshalb so partitioniert wurde. Wer so etwas macht (professionell!!!), den sollte man teeren und federn

Siehe: CB Forum = Beitrag: neue HDD: nach Formatierung noch Datenträgerprüfung sinnvoll ? #6

 

[synfor]

SHR ist proprietärer Consumer Kram um Heimanwendern die Entscheidung abzunehmen, welcher Raid Level der Beste für die jeweilige Bestückung ist.

Der proprietäre Consumer Kram betrifft aber nur den Speichermanager zum Einrichten des SHR. Ansonsten ist das alles doch auch nur LVM und mdamin oder?

Die Arrays werden bei einer Raid-Gruppe über den Logical Volume Manager zu einem Pool zusammen gefasst.

Also genau so wie beim SHR auch.

Was ist eine RAID-Gruppe?
Was ist Synology Hybrid RAID (SHR)?

Oder wenn man später doch noch auf größere Festplatten umziehen möchte?

Dann musst in deiner DS420+ alle 4 Platten tauschen, egal ob RAID6 oder SHR-2.

 

[himitsu]

Jupp RAID-Gruppen sind technisch auch nur das Gleiche, wie SHR,
nur das dort wohl auschließlich Platten nebeneinander verwaltet werden, während SHR auf voller Breite arbeitet und die Platten ihrer Länge nach stückelt ... es bleibt mdadm zusammen mit lvm2.

Wenn man jetzt Beides einfach mal kombinieren würde, dann wäre das fast die eierlegende Wollmilchsau.


Ja, SHR2 hat bei 4 Platten, sowie SHR bei 2-3 keinen Vorteil (jetzt) ... später, wenn man auf eine größere DS migriert, dagegen schon.
Und bei weniger Geldeinsatz ist es von Vorteil nicht erst alle Plassen aufrüsten zu müssen, bevor es mehr wird.

 

[DS214x20220109]

Um Bit Rot zu verhindern brauchst du btrfs Prüfsummen, das Raid alleine kann das nicht. Es muss regelmäßig ein Data Scrubbing und ein Raid Scrubbing laufen. Synology kombiniert das bereits so, dass deine Daten auf einem NAS mit btrfs und Prüfsummen bestmöglich geschützt sind.

Bin auf einen älteren Beitrag aus dem Jahr 2016
im ComputerBase Forum aufmerksam geworden.

Titel: Synology DS716+ im Test mit Prüfsummen und Snapshots gegen Datenverlust

Frank der Chefredakteur schrieb darin im Beitrag #119 folgendes:

Synology hat uns nun bestätigt, dass die DS716+ keine bitrot-correction unterstützt,
sondern lediglich Fehler feststellt und meldet.
Dies ist nun auch im Artikel entsprechend vermerkt.
Eine automatische Korrektur findet somit nicht statt.
Laut Synology sei der Schutz zu ineffizient und benötige zu viel Speicherplatz,
weshalb an einer eigenen Lösung gearbeitet werde.

Ist denn mitlerweile an einer eigenen Lösung gearbeitet worden?

Wenn ich bloss wüsste was sich von 2016 bis jetzt im Jahr 2022
so alles getan hat zwecks BTRFS und Bit-Rot Erkennung oder Korrektur in Synology NAS Geräten..

Eigentlich würde das ja bedeuten, das bei Synology NAS Geräten die BTRFS als Filesystem
mit NON ECC RAM einsetzen, überhaupt keine Daten beim Scrubbing kaputt korregiert werden können
Hoffe das es bei der DS420+ auch noch so ist?
Mir würde eine Bit-Rot Erkennung völlig ausreichen, wenn sie denn überhaupt eines Tages mal auftreten sollte....

 

[nas-central.de]

Aber Raid 6 oder SHR2 haben doch genug Paritätsinformationen um bei einem Ausfall von 2 Festplatten
die Daten trotzdem wiederherzustellen?

Das betrifft nur Fehler, die ein Raid beheben kann. Bit-Rot gehört nicht dazu.

Wenn jetzt z.B. auf einer von den 4 Festplatten Bitfäule auftritt, dann liegt es doch daran das die eine Festplatte nicht mehr in Ordnung ist
und das man sie tauschen sollte? Das sieht man ja an den SMART Werten, falls sie nicht sofort den Geist aufgibt..

Diese Art von Data Corruption hat nichts mit dem Zustand der Festplatte zu tun. Der Controller der Festplatte merkt es nicht. Die Festplatte ist aus Controllersicht und von den Smart Werten her völlig in Ordnung.

Wird die Bit-Rot Korrektur gar nicht unterstützt weder vom Raid 6 bzw. SHR2 ?

Raid kann das nur erkennen, nicht korrigieren.

Das eingesetzte BTRFS Filesystem über mdadm? von Synology,
kann nur Bit-Rots erkennen und nur eine Fehlermeldung ausgeben?

BTRFS mit Prüfsummen kann in Verbindung mit dem Raid Data Corruption erkennen und korrigieren

 

[DS214x20220109]

Das betrifft nur Fehler, die ein Raid beheben kann. Bit-Rot gehört nicht dazu.

Okay, danke das hilft mir schon mal weiter

Könntest du mir noch die restlichen Fragen aus Beitrag #26 beantworten,
falls du Informationen darüber hast?

Bin auf einen älteren Beitrag aus dem Jahr 2016
im ComputerBase Forum aufmerksam geworden...

 

[nas-central.de]

Und selbst wenn ein Bit kippt wird man das fast nie merken (kann ein Pixelfehler in einem Foto sein, oder in einem Videobild). Und selbst wenn noch etwas auftritt, bei momentan knapp 20TB Tendenz steigend wäre ein defekter Pixel oder gar jpg nicht relevant.

Zitat aus dem CB Forum / Beitrag: Synology DS716+ im Test: Mit Prüfsummen und Snapshots gegen Datenverlust #9

Das ist völliger Unsinn, was hier behauptet wird. Richtig ist, dass nicht alle Dateitypen gleich anfällig für Bit-Rot sind. Bei einem Videostream ist es in der Regel völlig egal. Bei den meisten Bildformaten reicht ein gekipptes Bit, um das Bild vollständig zu zerstören. Bei einer Textdatei ist es in der Regel egal, wenn ein Zeichen kippt, wenn es Programmcode ist sieht die Sache wieder anders aus.

Generell kann man sagen, dass Bitfäule besonders für komprimierte oder verschlüsselte Formate problematisch ist, weil ein einziges Bit das Entpacken der kompletten Datei ab der Stelle des Fehlers verändert oder das Entschlüsseln verhindern kann. In vielen Dateiformaten steckt Kompression, das ist gar nicht immer so klar wo und wo nicht.

 

[himitsu]

Es kommt auch drauf an, wo es gekippt ist.

Bei einem Bitmap betrifft es eventuell nur ein/wenige Pixel.
Bei einem JPEG oder Videos auf JPEG-Basis, betrifft es einen Block aus 8x8 Pixeln.
Viele Videos/Streams sind teilweise fehlertoleranter, für Fehler/Abrüche, wo dann eventuell ein Frame/Block (paar Sekunden, bis zum nächsten Vollbild/KeyFrame) betroffen sind.

Eine RAR kann man mit zusätzlichen Fehlerdaten packen, welches Fehler in gewissem Maße beheben kann.
(wird dann das größer, je mehr Fehler es beheben können soll ... z.B. bis 20% defekt, müssen mindestens diese 20% zusätzlich drin sein)

Aber hat es die Verwaltungsdaten des Bildes/Videos erwischt, dann kann auch alles futsch sein.

Auch Programme könnten eventuell noch "laufen", falls unwichtige Daten betroffen sind (z.B. paar Buchstaben im Text eines Knopfes), oder es "Freiräume" im Allignment erwischt hat.



Tja, früher hatte man bei Regen nur bissl Grieß.
Jetzt fehlen gleich halbe Bilder und sekundenlang Schlieren, oder garnichts mehr zu erkennen, weil alles stockt, wo man damals im grauen Muster immernoch den Schatten des Bildes erahnen konnte.

 

[Minzkeks]

Welche Daten sind das denn, die so dringend vor Bit-Kippern geschützt werden müssen, dass du das Checksum-Feature von BtrFS brauchst?

Allgemeine Dateien wie Bilder, Musik, Videos, Word, Text und PDF Dokumente und einige Zip Dateien.

Kein Grund, sich bei normalen Daten verrückt zu machen. Bitkipper können genau so passieren, wenn du die Dateien auf einem nicht-ECC Client bearbeitest. Nur das NAS besonders sicher zu machen allein würde nicht ausreichen für vermeintlich perfekte Sicherheit.

Ich halte einfache Backups da für deutlich wichtiger als BtrFS Checksums.

Ich habe bereits mehrfach Zeit verbrennen dürfen wegen BtrFS ENOSPC-Problemen. Mit ext2/3/4 hatte ich bisher noch nie Probleme. BtrFS-Checksums mögen theoretische Vorteile bieten, dafür holt man sich jedoch andere BtrFS-Probleme herein, die den theoretischen Vorteil locker wieder zunichte machen.

Darum sollte man ja auch ECC RAM beim BTRFS Filesystem verwenden.

Du machst dich mit der unnötigen Perfektionierung einer einzelnen Stelle verrückt.

Die BtrFS Checksums werden nicht deine Daten retten. Ich habe bisher nur von einem einzelnen Fall beim Größteinsatz von BtrFS bei Facebook gelesen, wo die Checksums einen Nutzen gebracht haben und auf ein Problem aufmerksam gemacht haben. Aber ich kenne viele Fälle, wo jemand durch kleinere oder größere BtrFS-Probleme Zeit oder Daten verloren hat.

Wenn du an deinen allgemeinen Daten hängst: regelmäßige am besten automatisierte Backups! BtrFS Checksums halte ich für nett, aber auch verzichtbar. Der Nutzen ist ziemlich klein. Wenn es wirklich Probleme mit deinen Platten oder der Hardware gibt wirst du das wahrscheinlich an anderen Stellen bemerken und nicht durch Datensalat in deinen Daten, was BtrFS dann reparieren könnte.

BtrFS auf Synology bringt Snapshots. Davon kann man wirklich etwas haben.

 

[Minzkeks]

Bei den meisten Bildformaten reicht ein gekipptes Bit, um das Bild vollständig zu zerstören.

Schöne Theorie. Wie viele Bilder hast du schon nachweislich durch Bitkipper verloren, wann hast du das erkannt?

Wie oft hattest du im Vergleich dazu Datenverlust durch Anwenderfehler, fehlende Backups, Abstürze, defekte Hardware usw.?

Um die Antwort vorweg zu nehmen: auf halbwegs vernünftiger Hardware ist das Risiko von Bitfehlern im NAS für einzelne Bilder praktisch irrelevant und nur eine akademische Theoriediskussion. Es knallt vorher an anderen Stellen, bevor sich sowas in nennenswertem Ausmaß verwirklicht. Deshalb gibt es keinen großen Trend hin zu Daten-Checksums, sondern es ist nur eine nice to have Funktion von BtrFS, die aber kaum jemanden zum Umstieg veranlasst.

 

[Minzkeks]

SHR ist proprietärer Consumer Kram um Heimanwendern die Entscheidung abzunehmen, welcher Raid Level der Beste für die jeweilige Bestückung ist. Das wird im Enterprise Bereich niemand anrühren. Die Arrays werden bei einer Raid-Gruppe über den Logical Volume Manager zu einem Pool zusammen gefasst.

Hast du eine Ahnung, wo LVM überall eingesetzt wird. LVM ist seit vielen Jahren im Enterprise-Bereich breit im Einsatz. Möglicherweise warst du noch gar nicht auf der Welt, als in Unternehmen schon mit LVM gearbeitet wurde. Die Linux-Implementierung kam später, bei AIX gibt es LVM schon über 30 Jahre. AIX LVM: https://www.ibm.com/docs/en/aix/7.2?topic=management-logical-volume-manager

Nur weil Synology einen Produktnamen für LVM verwendet ist das kein "Consumer Kram um Heimanwendern die Entscheidung abzunehmen".

 

[Minzkeks]

Als Synology-Neuling wollte ich der BtrFS-Konfiguration von Synology eine Chance geben. Immerhin bewirbt Synology BtrFS-Funktionen und unterstützt es seit 2017, es sollte demnach eine gewisse Reife z. B. durch zyklisch automatisiert laufende Rebalancings vorhanden sein (habe ich seit Jahren stündlich als Job laufen).

Habe ein knapp 1 TB großes BtrFS-Volume angelegt, um Daten von einem gleich großen ext4-Volume zu sichern, über rsync.

Es kam, wie es kommen musste: nach 637 GB transferierten Daten war das BtrFS Dateisystem "voll" (ENOSPC, no space left on device), obwohl noch 253 GB bzw. 28% physisch Platz vorhanden wäre. Für so ein Verhalten, dass man BtrFS-Dateisysteme bitte entweder nur langsam beschreiben darf oder aber dauernd Rebalancing im Hintergrund laufen lassen muss, damit das BtrFS nicht vorzeitig voll läuft hat kaum ein Anwender Verständnis.

Ich hätte erwartet, dass Synology beim DSM 7 automatische Routinen laufen lässt, die ein BtrFS-Rebalancing anstoßen, bevor das BtrFS voll läuft. Jetzt Stunden später ist das Rebalancing offensichtlich fertig, aber zu spät: mein rsync ist abgebrochen und ich habe erneut wieder durch BtrFS Zeit verloren.

BtrFS mag mit den Snapshots coole Funktionen bieten, aber der Preis um die zu erhalten ist immer noch zu hoch. Im Alltag muss es einfach funktionieren, es kann nicht sein, dass bei 72% physichem Füllgrad eines Volume dieses bis zum nächsten Balancing-Lauf voll ist und nicht mehr weiter beschrieben werden kann. Schade.

Ich bin dann wieder auf ext4. Stabilität, Einfachheit und Vorhersagbarkeit sind wichtiger als nette BtrFS-Features. Vielleicht bekommt BtrFS für den Virtual Machine Manager noch eine Chance.

 

[tproko]

Snapshots sind nett, und VMM läuft nur mit btrfs.

Bei mir läuft btrfs auf 2 NAS ohne Probleme und auch das ENOSPC warnkein Problem beim initalen Einspielen der Daten.

Was mir aber negativ aufgefallen ist: die verwendete btrfs Version hängt vom Modell ab. Dh. je nach Modell/Alter muss man dann mal das richtige Linux Derivate finden, um dann via mdadm, lvm und btrfs ein Raid im Notfall auszulesen. Gibt dazu einem Faden hier im Forum.

 

[Minzkeks]

Snapshots sind nett, und VMM läuft nur mit btrfs.

Snapshots sind eine praktische Funktion, die ich gerne nutze. Aber nur auf einem stabilen Filesystem, wo man möglichst wenig administrieren und nicht so viele Details beachten muss wie bei BtrFS.

Bei mir läuft btrfs auf 2 NAS ohne Probleme und auch das ENOSPC warnkein Problem beim initalen Einspielen der Daten.

Wenn man ein BtrFS nur wenig und langsam beschreibt und viel Platz frei lässt wird man kaum ENOSPC-Probleme bekommen.

Ich kann damit umgehen, ich kenne die Befehle, kann mir Jobs bauen, so dass fortwährend rebalanced wird und dann hoffen, dass es in der Nutzung stabil läuft. Macht aber wenig Spaß und man hat neue Sorgen, statt einfach nur ein verlässlich stabil primitiver aufgebautes Dateisystem.

Was mir aber negativ aufgefallen ist: die verwendete btrfs Version hängt vom Modell ab. Dh. je nach Modell/Alter muss man dann mal das richtige Linux Derivate finden, um dann via mdadm, lvm und btrfs ein Raid im Notfall auszulesen. Gibt dazu einem Faden hier im Forum.

Neuere BtrFS-Tools aus neuen Linuxkernels sollten ältere BtrFS ebenfalls ansprechen können.

Ich würde BtrFS gerne vermehrt einsetzen, aber es ist selbst in 2022 immer noch nicht stabil genug out of the box um damit wahlfrei einfach Daten so schnell und so oft zu schreiben, wie man das im Rahmen des physisch zugewiesenen Platzes mit klassischen Filesystemen kann. Leider.

 

[tproko]

Neuere BtrFS-Tools aus neuen Linuxkernels sollten ältere BtrFS ebenfalls ansprechen können.

Was sie sollten ist schön und gut, es ging leider trotzdem nicht...
Offensichtlich hast du da dein Glück bei Synology Raids noch nicht versucht?
Wir haben damals lange gesucht und probiert, bis die richtigen "eher alten" Linux Distributionen gefunden wurden.
Mit Fedora 33 damals (ca. 1 Jahr her), konnte man mit btrfs-tools die Platten der DS416play nicht lesen. Mehr dazu hier. Mit Linux Mint 18 ging es bei mir.

Generell... es zwingt dich ja niemand zu btrfs, dann nimm ext4. Verstehe ich voll und ganz, ext4 ist schon gefühlt ewig im Einsatz und hat sich bewährt auf herkömmlichen Server-Systemen (zumindest vor den CloudServices / Kubernetes etc.). Aber das von dir beschriebene Katastrophen-Szenario mit alle Daten sind weg, habe ich ei Synology in Kombination mit btrfs ehrlich noch nie gelesen hier im Forum oder auf Reddit.

Etwas Off-Topic: auch die andere Panik die hier öfters auftaucht, mit "btrfs kann kein Raid5/Raid6" ist fehl am Platz, da es da um ein natives Raid geht (btrfs supported da offiziell nur Raid1). Aber via mdadm/lvm ist das eben doch eine Möglichkeit, ein raid5 oder raid6 mit btrfs als Dateisystem darunter zu betreiben.

 

[Minzkeks]

Was sie sollten ist schön und gut, es ging leider trotzdem nicht...
Offensichtlich hast du da dein Glück bei Synology Raids noch nicht versucht?

Ich hatte bisher noch nicht den Fall, dass ein BtrFS nicht mehr lesbar/einhängbar war. Aber ich hatte schon zu viele Fälle, wo viele Schreiboperationen ein unbalanciertes BtrFS mit ENOSPC hinterlassen haben, mit nachfolgenden Problemen und Zeitverlust, wenn eingeplante Aktionen nicht wie geplant stattfinden konnten.

Meine Hoffnung war, dass der Reifegrad der BtrFS-Konfiguration von Synology höher ist als das, was ich seit 2015 an negativen Erfahrungen sammeln durfte. BtrFS ist ja bis 2018 schon deutlich gereift. Unkomplizierte Tauglichkeit für jedermann sehe ich zumindest mit der Synology Konfiguration aus 2022 mit den btrfs-tools aus dem Linux-Kernel 4.4.180 noch nicht.

Einfach gesagt muss ein Desktop-Anwender seine Daten auf einem BtrFS-Volume mit voller Geschwindigkeit ablegen können bis das Volume voll ist, ohne dabei an die Grenzen des automatischen Rebalancings zu stoßen.

Ich habe zudem nur eine langsame 2,5" SSHD mit 5.400 upm mit BtrFS beschrieben. An SSDs mit BtrFS Volumes möchte ich gar nicht denken, die können noch viel schneller viel mehr writes pro Sekunde aufnehmen und mit copy on write voll laufen.

Wir haben damals lange gesucht und probiert, bis die richtigen "eher alten" Linux Distributionen gefunden wurden.
Mit Fedora 33 damals (ca. 1 Jahr her), konnte man mit btrfs-tools die Platten der DS416play nicht lesen. Mehr dazu hier. Mit Linux Mint 18 ging es bei mir.

Generell... es zwingt dich ja niemand zu btrfs, dann nimm ext4. Verstehe ich voll und ganz, ext4 ist schon gefühlt ewig im Einsatz und hat sich bewährt auf herkömmlichen Server-Systemen (zumindest vor den CloudServices / Kubernetes etc.). Aber das von dir beschriebene Katastrophen-Szenario mit alle Daten sind weg, habe ich ei Synology in Kombination mit btrfs ehrlich noch nie gelesen hier im Forum oder auf Reddit.

Wo habe ich geschrieben alle Daten sind weg? Davon habe ich bisher nur gelesen, das habe ich mit BtrFS bisher in 7 Jahren noch nicht erlebt.

Etwas Off-Topic: auch die andere Panik die hier öfters auftaucht, mit "btrfs kann kein Raid5/Raid6" ist fehl am Platz, da es da um ein natives Raid geht (btrfs supported da offiziell nur Raid1). Aber via mdadm/lvm ist das eben doch eine Möglichkeit, ein raid5 oder raid6 mit btrfs als Dateisystem darunter zu betreiben.

Wenn man vermutet, dass der Stand des btrfs-Kernelmoduls aus Kernel 4.4.180 von Mai 2019 aus dem damals aktuellen Kernel 5.0 zurück portiert wurde könnte folgende Liste der stabilen/instabilen BtrFS-Features für Synology gelten:
https://btrfs.wiki.kernel.org/index.php?title=Status&oldid=32759

Nicht vollständig stabil wären demnach: Defragmentierung, Raid5/6 nativ in BtrFS ohne MD-RAID darunter (hier nicht im Einsatz) und Quotas. Quotas werden von Synology sogar extra beworben.

Für mich ist BtrFS auf der Synology für den allgemeinen Einsatz wieder aus der Wahl gefallen. Zu instabil, zu kompliziert, die Probleme übersteigen den Nutzen. Beim VMM spiele ich bestimmt nochmal damit herum.

Vielleicht ist BtrFS dann um 2030 herum stabil für alle Anwendungen selbst mit hoher Schreiblast? Ich bin gespannt.