Neben den Daten in den Dateien selbst, können bei RAM Fehlern auch die Metadaten des Filesystems korrupt werden und dies kann zum Komplettverlust des Filesystems führen, auch bei den Filesysteme mit Pürfsummen. Solche Filesystem sollte man daher immer nur zusätzlich aber nicht anstelle von ECC RAM (und natürlich dem passenden Board sowie der passenden CPU die auch die ECC Funktion unterstützen), sondern zusätzlich als weitere Sicherheitsstufe betrachten.
Das man vorher von Datenkorrpution erfährt, ist ohne ECC RAM auch nicht garantiert, denn die Dateien können schon vor dem Schreiben von RAM Fehlern korrumpiert worden sein, da sie ja vorher im RAM liegen, auch wenn sie z.B. übers Netzwerk übertragen wurden und dann berechnet das Filesystem die Prüfsummen eben schon für diese korrupte Version der Datei und wiegt den Nutzer in eine falsche Sicherheit.
Außerdem ist es eben ein Mythos, dass HDDs falsche Daten wiedergeben würden, die passiert wegen FW Bugs oder wenn es Probleme auf ihren Datenpfaden gibt, wogegen bessere HDDs und SSDs aber geschützt sind. Vielmehr geben HDDs und SSDs Lesefehler statt korrupter Daten zurück, wenn die Daten eines Sektors (bzw. bei SSDs i.d.R. einer Page) nicht zur ECC passen, die der Controller selbst dahinter ablegt. Es ist dann die Aufgaben der Software die die Daten lesen will, mit diesem Lesefehler korrekt umzugehen und keine halbgelesene Datei einfach so anzuzeigen als wäre alles gut gewesen. Bei einem klassischen Hard- oder Software RAID mit Redundanz fängt das RAID diesen Lesefehler ab, liest dann und nur dann die Redundanzdaten aus, korrigiert damit die fehlenden Daten und überschreibt auch gleich noch den Sektor auf der Platte bei dem der Lesefehler aufgetreten ist, weshalb solche HDDs keine schwebenden Sektoren (das sie die bei denen die Daten nicht zur ECC passen und beim Überschreiben des Sektors gleich wieder verschwinden) zeigen, sondern allenfalls wiederzugewiesene Sektoren (wenn der Controller der Platte die "neuen" Daten nach dem Überschreiben nicht korrekt lesen kann, dann verwendet er einen Reservesektor anstelle des defekten Sektors und nur dann ist dort wirklich ein Defekt auf der Oberfläche der HDD vorhanden).
Übrigens ist auch die Übertragung der Daten von der Platte zum Host Controller abgesichert, bei SATA mit einer CRC32 pro Datenpaket (FIS genannt), welches bis zu 8192 Byte Nutzdaten enthalten kann und die Wahrscheinlichkeit das Bitfehler dabei unerkannt bleiben, liegt irgendwo im Bereich von 1:10^46, was mal 8k ein Datenvolumen ergibt, welches um Größenordnungen über der Kapazität aller bisher gefertigten HDDs und SSDs liegt. Diese CRC32 Absicherung wurde überigens schon bei IDE mit dem Ultra-DMA Modus zusammen eingeführt und daher wird sie auch oft noch Ultra-DMA CRC genannt. Wenn ein Übertragungsfehler erkannt wird, muss die Übertragung wiederholt werden.
Daher würde ich es immer mit Matt Ahren, einem Mitentwickler des ZFS-Dateisystems, halten, der schreibt: Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann erst obendrauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!
PS:
Hier ein Review verschiedener Filesysteme unter Linux auf zwei Optane 900P als Singledrive, sowie im RAID 0 und 1, ebenso mit ZFS On Linux 0.8.1, auch im RAIDZ.
