btrfs Prüfsummen ohne ECC RAM blödsinn?

[Christian1297]

Hi,

Ich habe schon einiges zum btrfs Dateisystem gelesen und bin noch am überlegen ob ein Umstieg zwecks Schutz vor bitrot sinnvoll ist.

Die Meinungen gehen ja nun auseinander ob das ohne ECC RAM überhaupt sinnvoll ist. Manche sagen sogar dass die Daten kaputt repariert werden.

Ich bin jetzt an ein paar weiteren, aktuellen Meinungen zum Thema interessiert, wie seht ihr das?

 

[KillerCow]

Ohne ECC Ram hast du weiterhin den Schutz vor Bitrot oder anderweitig provozierten Veränderungen auf der Platte.

 

[Christian1297]

Der Schutz basiert doch aber darauf, dass Prüfsummen für jede Datei hinterlegt werden, welche beim lesen gegengeprüft werden.

Was aber wenn die Prüfsumme fehlerhaft berechnet wurde weil ein Bit im RAM kippt ist?

 

[Mickey Mouse]

das eine hat doch mit dem anderen (so gut wie) gar nichts zu tun.
einmal sind das Fehler auf dem Dateisystem, das andere Mal im Speicher. Beides steht in keinerlei kausalem Zusammenhang!

 

[whats4]

die problematik ist real.
und die fragestellung deswegen eine gute und gescheite.
andererseits:

allein die fragestellung hat bereits die antwort inhärent:

wenn das dateisystem so robust wie möglich sein soll/muß, so macht das nur wirklich sinn, wenn man das bit-kippen im speicher durch ecc ausschließt.
es gibt halt mehr als leuchtende gaming kisten.

 

[Piktogramm]

@Christian1297
Solang es ein zufälliger Fehler im Ram war, wird beim nächsten Leseversuch der Fehler nicht nochmal auftreten.

Für systematische Fehler im Ram ist es ein Problem. Wenn bei Erstinbetriebnahme der RAM gescheit getestet wird und das System innerhalb seiner Spezifikationen läuft ist es recht unwahrscheinlich, dass später solche systematische Fehler auftreten.

Edit: "kaputt reparieren", die invasiven Reparaturversuche sollte man nicht auf "auto" stellen. Sinnvoll ist es, dass das System bei festgestellten Fehler ins Log schreibt (aufpassen, journald speichert in seiner standardconfig keine Logs!) und das Dateisystem auf "read only" setzt. Automatisierte Fehlerkorrektur bringt Probleme

@whats4
Erfahrungsgemäß sieht die Bedrohungslage so aus:
Nutzer[2] >> Hardware[1]> Software > Speicherfehler

ECC beim Memory ist so ziemlich das Letzte in der Kette.

[1] Ausfall, Verbindungen mit Wackelkontakt
[2] Jub auch als Besitzer/Betreiber der Speicherlösung, been there, done that

 

[wayne_757]

Was aber wenn die Prüfsumme fehlerhaft berechnet wurde weil ein Bit im RAM kippt ist?

Dann ist die Datei an der Stelle nicht mehr lesbar. Du kannst dann z.B. eine Version aus einem Backup nutzen.
Bitkipper kannst du ausschließen, wenn du Dateien korrekt wieder auslesen kannst (vor dem auslesen musst du nur gewährleisten, dass nicht aus dem cache gelesen wird). Ist die Leseoperation erfolgreich -> kein Bitkipper.

Im übrigen wird immer so getan als ob nur der Hauptspeicher davon betroffen wäre.
In der Regel wird in Festplatten/SSDs DRAM Cache verbaut und der hat? Richtig, auch kein ECC.

@Christian1297
Solang es ein zufälliger Fehler im Ram war, wird beim nächsten Leseversuch der Fehler nicht nochmal auftreten.

Er redet aber von der Schreiboperation.

die problematik ist real.

Man muss da mal realistisch bleiben.
Ja es gibt Bitkipper, ja das kann ein Problem geben.
In einem System mit 32 GB RAM hat über 274 Millarden Bits.
Und das Zeitfenster in dem in einem sehr eingeschränkten Bereich geschrieben wird ist irre kurz.
Solange man nicht wie bei ZFS Gigabyteweise Metadaten cached sehe ich da eher kein Problem. Ein Backup aus dem du zurückspielen kannst benötigst du sowieso.

 

[whats4]

aber die fragestellung ist/war eine prinzipielle.
keine der wahrscheinlichkeit.
btw: nur weil etwas relativ unwahrscheinlich ist, heisst es ned, daß es wurscht ist.

murphy's law läßt grüßen.

 

[Christian1297]

Ich konkretisiere mal:

Ich habe aktuell eine Synology DS216j mit einer Festplatte. Darauf werden regelmäßig neue Daten geschrieben, welche aber nur selten gelesen wieder werden. Eine zwischenzeitlich korrupt gewordene Datei würde unter Umständen nicht auffallen und später auch ins Backup übernommen werden.

Ich überlege nun ob ein Synology NAS mit btrfs der Datenintegrität zu gute kommt oder ich mir das Geld sparen kann. Eine zweite Festplatte für ein RAID 1 müsste ich ja auch anschaffen.

Von Synology wird es ja genau für solche Fälle beworben.

 

[Mickey Mouse]

oh man, ist das denn so kompliziert?
das eine hat mit dem anderen nichts zu tun!
dann muss man auch eine USV haben, wenn während des Schreibens der Strom ausfällt, dann hat man auch nichts vom ECC RAM.
und ja, bei "richtigen" Rechnern ist auch der HDD Cache/RAID-Controller Akku gepuffert und zusätzlich hängen die an der USV und die haben auch ECC. Aber nochmal, das sind alles verschiedene Dinge...

 

[Mr. Robot]

Vor allem bringt die BTRFS-Prüfsumme nur was, wenn auch Redundanz vorhanden ist, also RAID 1.
Bemerkt BTRFS dann einen Fehler, liest er einfach die Kopie ein. Ohne Redundanz erkennt er zwar einen Fehler, schaut dann aber dumm aus der Wäsche.

Davon abgesehen. ECC auf dem Server schadet natürlich nie. Aber merkwürdigerweise interessiert sich kaum jemand für ECC auf dem Rechner, auf dem die Daten erzeugt und verarbeitet werden. Da wäre ECC meiner Meinung nach sogar wichtiger als auf dem Server.

 

[pedder59]

Ihr redet alle von Server oder NAS.
Können Dateifehler nicht schön viel früher auftreten.
Z.B. im Client natürlich ohne ECC. Eine fehlerhafte Datei wird auf die lokale Platte gespeichert.
Dann nutzt der ECC im Server / NAS auch nix mehr.

 

[Christian1297]

Die Dateifehler die früher auftreten lassen sich aber in einigen Fällen nicht verhinden. Smartphones, DSLRs und andere consumer- und semiprofessionelle Geräte kommen ja eh ohne ECC und so weiter.
Möchte ich also beispielsweise regelmäßig Fotos ablegen bleibt mir ja nur diese beim aufspielen aufs NAS händisch zu sichten. Um die Integrität des Archivs zu erhöhen ist btrfs dann eine mögliche Option.

 

[Piktogramm]

Ich überlege nun ob ein Synology NAS mit btrfs der Datenintegrität zu gute kommt oder ich mir das Geld sparen kann. Eine zweite Festplatte für ein RAID 1 müsste ich ja auch anschaffen.
Von Synology wird es ja genau für solche Fälle beworben.

BTRFS kann in solchen Fällen helfen und benötigt dazu nicht zwingend ECC Speicher.
ECC Speicher hilft beim spezifischen Problem kippender Bits im Hauptspeicher.

Ob man entsprechende Lösungen einsetzt ist eigentlich immer eine Abschätzung aus Risiko/Nutzen und Kosten. Für den Haushaltsgebrauch von einem Synology NAS mi 2 Einschüben würde ich zu eher nein tendieren. Da gibt es größere Risiken denen man begegnen sollte als das.

 

[Christian1297]

Das btrfs nicht zwingend ECC Speicher benötigt verstehe ich. Mein Gedanke ist nur, dass btrfs zuverlässiger funktioniert wenn ECC Speicher verbaut ist. Die von btrfs verwendeten Prüfsummen durchlaufen ja schließlich auch den RAM und könnten so von Fehlern betroffen seien.

 

[Piktogramm]

Davon abgesehen. ECC auf dem Server schadet natürlich nie. Aber merkwürdigerweise interessiert sich kaum jemand für ECC auf dem Rechner, auf dem die Daten erzeugt und verarbeitet werden. Da wäre ECC meiner Meinung nach sogar wichtiger als auf dem Server.

Wenn die Daten auf dem Clientsystem sensibel und wichtig sind, sollte man sich da Gedanken machen. Typischerweise schreiben Clienten ihre Nutzdaten aber sowieso in kurzen Abständen vom Ram aufs Laufwerk. Server hingegen halten Datenbestände gern mal über Tage im Ram vor. Was die Chance erhöht, dass da mal ein Bit kippt.
Ansonsten, Server sollten ihren Clienten sowieso immer misstrauen und eingehende Daten auf Plausibilität prüfen.

Die Dateifehler die früher auftreten lassen sich aber in einigen Fällen nicht verhinden. Smartphones, DSLRs und andere consumer- und semiprofessionelle Geräte kommen ja eh ohne ECC und so weiter.
Möchte ich also beispielsweise regelmäßig Fotos ablegen bleibt mir ja nur diese beim aufspielen aufs NAS händisch zu sichten. Um die Integrität des Archivs zu erhöhen ist btrfs dann eine mögliche Option.

Händische Sichtung bringt sehr wenig. Für Sowas gibt aus gutem Grund Prüfsummen bzw. Signaturen.

Ergänzung (16. Februar 2020)

Das btrfs nicht zwingend ECC Speicher benötigt verstehe ich. Mein Gedanke ist nur, dass btrfs zuverlässiger funktioniert wenn ECC Speicher verbaut ist. Die von btrfs verwendeten Prüfsummen durchlaufen ja schließlich auch den RAM und könnten so von Fehlern betroffen seien.

Können ja, die Wahrscheinlichkeit ist jedoch klein. Viel kleiner als viele andere Bedrohungsszenarien.

 

[aranax]

Möchte ich also beispielsweise regelmäßig Fotos ablegen bleibt mir ja nur diese beim aufspielen aufs NAS händisch zu sichten. Um die Integrität des Archivs zu erhöhen ist btrfs dann eine mögliche Option.

Und du glaubst, dass ein Bitfehelr bei Fotos auch nur irgendwas ausmachen würde?

Spricht man von Finanzdaten würde ich das ja noch einsehen, vllt. auch bei Steuerdaten für megagenaue Systeme. Aber @home spielen Bitfehler doch nachzeu nie eine nennenswerte Rolle...

 

[RalphS]

Weder zfs noch Btrfs schützen automatisch vor bitrot. Man muß schon periodisch das Dateisystem prüfen, zfs per scrubbing.

Die Anforderung ECC ist nicht mehr so rigoros. Man kann auch ohne. ECC greift in Verbindung dann, wenn ein Datum im RAM verändert werden könnte: wenn dann durch bitflip (nicht rot!) etwas falsches geschrieben wird, dann wird dieses falsche Datum nun per checksum validiert und erschlägt so intakte Kopien.

Bitrot dagegen sind altersbedingt kippende Bits. Um die zu finden muß man Datum gegen Prüfsumme validieren über den gesamten Datenbestand. Tu ich das nicht, wird irgendwann auch die letzte intakte Kopie krepieren - dann seh ich den Fehler (immerhin) aber kann ihn nicht beheben.

ECC unterstützt den Prozeß der Validierbarkeit, nicht mehr. Wenn ich 60TB Daten wegen scrubbing durch den RAM schiebe, darf ich mit relativer Sicherheit von mindestens einem Fehler dabei ausgehen.

Fotos? Interessieren keine Sau. Aber verschlüsselte Container, Archive etc sind mit Pech schon durch ein einziges falsches Bit komplett unbrauchbar. Das gilt auch für besonders eng komprimierte Multimediaformate- die Frage ist nur, ob der Decoder drüber stolpert oder den Frame verwirft.

Daß plötzlich in der Readme kein a, sondern ein b steht, wird niemand auf bitrot zurückführen. Nicht mal dann, wenn’s wirklich welcher war.

 

[Piktogramm]

Wenn ich 60TB Daten wegen scrubbing durch den RAM schiebe, darf ich mit relativer Sicherheit von mindestens einem Fehler dabei ausgehen.

Relative Sicherheit zu welchem Bezugswert?

 

[h00bi]

wenn das dateisystem so robust wie möglich sein soll

100% agree.
Warum sollte man bei so nem Aufwand (Neuinvestition) beim Storage beim RAM auf ECC verzichten?
Für mich ebenfalls völlig unlogisch.