Raid 6 & BtrFS ... Einige Verständnisfragen

[Ottest]

Servus Leute,

heute ist meine neue DS2419+ eingetroffen. Nun habe ich zum ersten Mal Kontakt mit BtrFS. Und ja, ich habe schon viel gesucht, recherchiert und gelesen. Vielleicht auch zu viel .
Also erstmal zum Platten-Unterbau. Es sind 4x16TB im Raid-6 Verbund verbaut und 32GB ECC-Ram. Ich habe mich fuer Raid-6 entschieden um schleichenden Bitfehlern entgegenzuwirken (Bit Rot). Nun zu meinen Fragen:

1. Macht BtrFS bzw die integrierte Self-Heal Funktion gegen Bit Rot ueberhaupt Sinn mit Raid-6? Mit einem monatlichen Paritaetscheck des Raid-6 muesste doch genau das gleiche wie mit der Self-Heal Funktion erfuellt werden?
2. Rattert diese Self-Heal Funktion permament im Hintergrund, oder nur bei Dateizugriff?
3. Ist ein Raid-5 mit BtrFS vergleichbar mit einem Raid-6 und konventionellem Dateisystem(z.B. Ext4)? Sprich, wenn eine Platte ausfaellt und diese ersetzt wird, koennen die Daten verlaesslich ohne Bitfehler wiederhergestellt werden?
4. Wie realistisch ist die Angabe der 5% fuer Metadaten in BtrFS?

Vielen Dank und beste Gruesse
Ottest

 

[Synchrotron]

Für mich war die Snapshot-Fähigkeit ausschlaggebend für die Entscheidung zugunsten von BtrFS.

Nachdem ich mit 2x WD 10TB als SHR begonnen hatte, mir das aber nicht gefiel (Speicher wurde knapp, und gefühlt waren die WD etwas träge), bin ich dann im laufenden Betrieb umgestiegen auf 3x IronWolf 12TB. Erst eine 12er dazu (weil ich schnell mehr Speicherplatz brauchte), dann eine 10er nach der anderen ausgetauscht und immer über „Volume reparieren“ ins SHR integriert.

Das hat alles reibungslos funktioniert. Jetzt kann ich schlecht sagen, weil BtrFS und SHR, weil es vermutlich anders aufgesetzt auch funktioniert hätte. Aber zumindest spricht aus meiner Sicht nichts dagegen.

 

[InDePeNdEnT64]

Mal dumm gefragt:
Wie lange dauert es, wenn Du eine 10TB gegen eine 12TB tauscht? Würde mich mal interessieren ...

 

[Synchrotron]

Habe es nicht wirklich gemessen, das ist ja kein Rennen. Basis: 418play, 10GB RAM, relativ geringe Systemlast während der Aktion.

Ein paar Tage hat es jeweils schon gedauert. Dadurch, dass ich das SHR zuerst um 12TB (netto 10TB, wegen dem gemischten Satz im SHR) erweitert hatte, hatte ich ja keinen Druck. Zuerst wurde die neue Platte integriert, so dass ich 3 hatte. Und dann kamen die WDs eine nach der anderen raus. Gefühlt hat die Integration der ersten, zusätzlichen Platte länger gedauert als der spätere Austausch.

 

[sunday88]

3. Ist ein Raid-5 mit BtrFS vergleichbar mit einem Raid-6 und konventionellem Dateisystem(z.B. Ext4)? Sprich, wenn eine Platte ausfaellt und diese ersetzt wird, koennen die Daten verlaesslich ohne Bitfehler wiederhergestellt werden?

Moin,

ich hab auf der 916+ ein Raid 6 mit BTRFS laufen. Bitfehler korrigieren hat erst mal nichts mit dem Raid Level zu tun. Raid 5 heißt, dass eine Platte ohne Datenverlust ausfallen kann. Bei Raid 6 sind es derer 2 Platten die ausfallen können. Ob nun EXT4 oder BTRFS ist dahingehend uninteressant.

Meine Überlegung bzgl der Konfiguration war damals so, dass ich Raid 6 wollte, damit ich eine größere Verfügbarkeit habe falls mal eine Platte aussteigt. Wie der Teufel es will, du hast eine defekte Platte, tauscht die aus und dann steigt beim rebuild eine weitere aus und das war es mit den Daten. Bei Raid 6 kann ich im Zweifel auch gleichzeitig 2 Platten tauschen oder halt den rebuild laufen lassen und danach die 2. Platte tauschen.

BTRFS habe ich genommen wegen der Snapshot Funktion. Ist m.E. Gold wert und ich habe es das ein oder andere mal schon genutzt.

Bzgl. der Zuverlässigkeit: Ich habe am Anfang mit 4 kleinen Testplatten angefangen und hab diese nach und nach gegen meine 6TB ausgetauscht. Jeweils immer den Rebuild laufen lassen und dann die nächste. Es hat dabei keinerlei Probleme mit den Datenkonsistenz gegeben.

Grüße
Frank

 

[Ottest]

Moin Moin,

danke erstmal für eure Antworten. Die Snapshot-Funktion ist sicherlich Nice-To-Have, aber interessiert mich in meinem Fall überhaupt nicht. Raid-6 hat schon etwas mit "Bitfehler-Korrektur" zu tun, da es meines Verständisses nach, der einzige Raid-Verbund ist, der Paritätsfehler erkennen und sofort reparieren kann. Raid-5 kann sie lediglich erkennen, aber weiß im Fall der Fälle ja nicht wo der Fehler aufgetreten ist.
Vielleicht hab ich dort aber auch einen Denkfehler
Freue mich nach wie vor auf eure Antworten, noch sehe ich kein Licht im Dunkel.

Beste Grüße
Ottest

 

[sunday88]

Raid-6 hat schon etwas mit "Bitfehler-Korrektur" zu tun, da es meines Verständisses nach, der einzige Raid-Verbund ist, der Paritätsfehler erkennen und sofort reparieren kann. Raid-5 kann sie lediglich erkennen, aber weiß im Fall der Fälle ja nicht wo der Fehler aufgetreten ist.

Soweit ich weiß hat der Raid-level erst mal nichts damit zu tun. Das ist eine Funktion von btrfs. Schnell und schmutzig durch Google gesucht scheint es, dass ich damit recht habe. Ich lasse mich aber gerne eines besseren belehren. Bin da nicht zu 100% drin.

Grüße
Frank

 

[Synchrotron]

Zum Thema 1 oder 2 Platten Sicherheit: Ein RAID ist kein Backup.

Daher reicht aus meiner Sicht eine RAID-Ausfallsicherheit von 1 Platte völlig aus. Fällt die erste aus, wird sie zeitnah getauscht. Es mag Systeme geben, die für den laufenden Betrieb mehrfach gesichert sein müssen - allerdings stelle ich Synology als Basis dafür in Frage.

Die Sicherheit der Daten muß über die Backup-Strategie gewährleistet werden.

 

[RichardB]

Raid-5 kann sie lediglich erkennen, aber weiß im Fall der Fälle ja nicht wo der Fehler aufgetreten ist.

RAID5 erkennt schlechte Blöcke und ordnet sie neu zu. Dabei wird die Parität neu berechnet und mit der gespeicherten für den Streifen verglichen. Und wenn die neue Parität nicht mit der gespeicherten übereinstimmt, wird die gespeicherte überschrieben. RAID6 hat als "Zusatzsicherheit" eben noch die Daten der "Q-Platte".

Nur das ist alles eine Frage des RAIDs und keine Frage des Dateisystems.

 

[Fusion]

Synology kombiniert hier die Paritätinformation des RAID mit den Prufsümmen von btrfs

https://blog.synology.com/how-data-scrubbing-protects-against-data-corruption/

Sehe das ähnlich wie RichardB
https://www.synology-forum.de/showt...ert-es-wirklich-auf-Synology-NAS-wie-beworben

 

[sunday88]

Also stimmt es es so halbwegs was ich gesagt habe. Egal ob Raid 5 oder Raid 6, effektiv ist BTRFS ausschlaggebend. Oder verstehe ich das falsch?

 

[Fusion]

Wenn ich es mal plakativ ausdrücken darf habe ich es so verstanden:
Grundlegend ist das RAID-scrubbing der Mechanismus der für die Datenwiederherstellung sorgt.
Die Integritätsprüfung mit btrfs und den Prufsümmen und Metaprüfsummen versetzt einen jetzt in die Lage das scrubbing selektiv nur dort anzuwenden, wo auch gerade eine Inkonsistenz in den btrfs Prufsümmen entdeckt wurde.
Bits die gekippt sind und nicht gerade beim Zugriff auffallen findet man halt nur dann wenn wieder ein Zugriff erfolgt oder eben eine btrfs Dateiprüfung oder ein raid-scrubbing über das gesamte Dateisystem/Volume läuft.

 

[Ottest]

Erstmal vielen Dank für eure Beiträge und Interesse am Thema!
Leider habe ich es immer noch nicht vollständig verstanden.

1) Ein Raid-6 liest doch, wenn ich eine Datei anfrage, von allen, im Verbund befindlichen, Platten. Dementsprechend müsste bei diesem Vorgang doch auch die Konsistenz/Integrität der Daten geprüft werden, richtig?
2) Was passiert, wenn bei einem solchen Lese-Prozess ein Fehler festgestellt wird? Wird dieser automatisch sofort korrigiert (also auch korrekt zurückgeschrieben)?
3) Wofür dann noch eine BtrFS "Heilfunktion"? Wäre doch überflüssig, oder nicht?
4) Selbst, wenn ein Raid-6 Fehler nicht direkt korrigiert, müsste doch spätestens ein monatliches Raid-6-Scrubbing eine BtrFS-Heil-Funktion ersetzen oder?

Bei einem Raid-5 macht diese Selbstheil-Funktion ja irgendwie noch Sinn, aber bei einem Raid-6?

Beste Grüße
Ottest

 

[RichardB]

siehe #12 - prägnanter kann man es kaum zusammenfassen.

Du vermischt nach wie vor den Datenverlust durch Hardwareausfall mit dem Datenverlust durch nicht korrigierbare Schreib/Lesefehler.
Auch ein RAID5 liest von allen im Verbund befindlichen Platten und speichert auch darauf.

Der Unterschied zwischen RAID5 und 6 ist, dass bei letzterem die Paritätsdaten doppelt vorhanden sind. Daher können (n-2) Platten ausfallen ohne dass die Daten verloren gehen. Im RAID5 sind es halt nur (n-1) Platten. Der Preis für diese zusätzliche Redundanz ist der Speicherplatz, den der zweite Paritätsdatensatz benötigt und die geringere Schreib-/Lesegeschwindigkeit der RAID6-Konfiguration. Demgegenüber steht die mögliche Write-Penalty im RAID5, der man mit einer ungeraden Anzahl an betriebenen HDDs gut begegnen kann (stark vereinfacht gesagt).

Bitfehler können in beiden Konfigurationen auftreten und für ihre Korrektur ist es letzlich egal, wie oft die Paritätsdaten gespeichert sind.

Was Dir möglicherweise RAID6 so verführerisch erscheinen lässt, sind jene Implementierungen, die mit nur einer Datenzeile rechnen und dabei keine Paritätsbits, sondern eine Zusatzcode produzieren, der 2 Einzelbitfehler beheben kann. Allerdings ist die Mehrbitfehlerkorrektur ein Thema, zu dem ich nichts weiter beisteuern kann.

 

[Ottest]

Also ich denke ich wechsel dann doch zurück zu EXT4. Die Features von BtrFS (Komprimierung, Snapshots, Defrag) nutze ich nicht und der Mehrwert den Checksums und Selfheal erschliesst sich mir nicht. Auch, dass es keine wirklich Angabe dieser Funktion zum zusätzlichen Speicherverbrauch sowie Hintergrundaktivität gibt, macht die Sache nicht besser.
Also: Never touch a running system. EXT4 scheint mir dann doch erprobter und zuverlässiger

Vielen Dank nochmal und beste Grüße
Ottest

 

[Fusion]

Bei ext4 hast du auch keine Angabe wie viele X Bits du auf dem Dateisystem brauchst um Y Bits abzuspeichern.
So was lässt sich aber recherchieren. Btrfs belegt etwa 4%,Nachkommastellen weiß ich grad nicht, des Volumes VOM Start weg für sich (bei ext4 war es glaube 0.x%). Kleine Dateien werden dann teils mit abgespeichert in dieser Struktur ohne Platzbedarf. Ob man die Integritätsfunktion aktiviert oder nicht habe ich keinen signifikanten Mehrverbrauch feststellen können (vermutlich geht das im Initialen Platzverbauch mit auf).

Ja,ext4 ist älter und erprobter, aber von Syno bekommst weder zum einen noch zum anderen Infos zu den angesprochenen Punkten.

 

[Adama]

Man darf auch nicht vergessen, dass die Standardtools du und df von Linux nicht klar kommen mit den Eigenheiten von BTRFS.

Z.b. beherrscht BTRFS unter anderem Datenkompression.

Man soll dafür btrfs filesystem df/du bzw. btrfs filesystem usage nutzen.