Erstens hat auch das DS716+ die Prüfsummen nur zur Erkennung und nicht auch Korrektur bei Fehlern aktiviert und zweitens ist das auch gut so und verantwortungsvoll. Das DS716+ hat nämlich genauso wenig ECC RAM wie das DS415+, wobei es beim DS415+ wirklich unverständlich ist, da dessen Atom C2538 sogar ECC RAM unterstützen würde, man hat nur eben keines verbaut, weil die NAS Hersteller diese Feature nur den ganz teuren Kisten spendieren.
Filesysteme mit Fehlerkorrektur über Prüfsummen sind aber ohne ECC RAM nicht nur Schwachsinn, sondern sogar gefährlicher Blödsinn. Schwachsinn ist es, weil HDDs praktisch nie falsche Daten rückliefern, die liefern dann einen Lesefehler und keine korrupten Daten, wenn die Daten eines Sektors nicht zur ECC dahinter passen. Das dies unerkannt bleibt, also die Daten falsch sind und trotzdem zur ECC passen, ist so gut wie ausschlossen. Die Übertragung über SATA wird ebenfalls abgesichert, da gibt es eine CRC32 hinter jedem FIS, also jedem Übertragungspaket welches bis zu 8192 Bytes Nutzdaten haben kann und das reicht um nur etwas weniger als einen von 10^40 Fehler nicht zu erkennen, das mal 8k ist ein Datenvolumen größer als das Internet und da man Ultra-DMA Fehler wegen der Verzögerung bei der Übertragung und in den S.M.A.R.T. Werten sowieso erkennt, sollten die sowieso behoben werden, also praktisch dürfte wohl noch nie ein Fehler bei der SATA Übertragung unbemerkt geblieben sein.
Damit bleiben nur Fehler auf den internen Datenpfaden oder Fehler aufgrund von FW Bug der Platte oder des Host Controllers die so eine Prüfsumme erkennen kann und die man sonst nicht durch Lesefehler von der Platte erkannt hätte. Solche Lesefehler sind bei einem funktionierenden echten RAID (also kein RAID 0) dann aber auch kein Problem, da über die Paritydaten die Daten rekonstruiert und wieder auf die Platte mit dem Fehler geschrieben werden. Nur dann liest ein normaler Linux SW RAID überhaupt mal die Paritydaten aus. Ein FS mit Prüfsummen liest die immer (geht auf die Performance) und meldet jeden Fehler, nur wenn der Fehler im RAM passiert ist weil eben kein ECC RAM verwendet wird, denn gibt es mindestens mal einen Fehlalarm das eine Datei korrupt sein.
Wird nun aber auch die Fehlerkorrektur verwendet und die Paritydaten bzw. Prüfsumme ist gerade in dem RAM Bereich wo ein Fehler vorliegt, denn wird es schnell kritisch, diese Filesysteme trauen ihren Prüfsummen nämlich mehr als den gelesenen Daten und korrigieren den vermeidlichen Fehler und schreiben die nun kaputtkorrigierten Daten zurück. Bei einem hard-error der RAMs, also einem wiederholt an bestimmten RAM Adressen bei stimmten Bitmustern auftretenden Fehler, frisst sich der Fehler dann wie ein Krebs durch die Daten und wenn die Metadaten betroffen sind, ist der Pool kaputt und mit Pech hat man die korrupten Daten schon auf dem Backup. Berichte von Leute denen sowas mit ihren ZFS Pools auf Consumer-HW ohne ECC passiert ist, finden sich zu genüge im Netz.
Dagegen ist das was bei einem Linux md SW-RAID bei RAM Fehlern passiert geradezu harmlos, denn die RAID sind ja nicht auf zugleich Filesysteme, wie eben ZFS und BTRFS, die beides sind, RAID und Filesystem. Auf einem md-RAID kann man jedes Filesystem verwenden, die Daten des Filesystems werden vom darunter liegen Layer des RAIDs daher auch nie geändert, außer eben bei der oben beschrieben Rekonstruktion, aber die ändert ja auch keine Daten. Gibt es hier einen RAM Fehler, werden die Daten oder die Parity falsch geschrieben, sind die Daten betroffen war es das, aber bei ZFS oder BTRFS ist das nicht anders, wenn die Daten von der Netzwerkkarte kommen und in einem RAM Bereich mit einem Fehler landen, werden die vom Filesystem auch schon verändert gelesen, die Prüfsumme wird über die korrumpierten Daten gebildet und der Fehler ist permanent, man fühlt sich nur in der falschen Sicherheit sie wären korrekt.
Wird beim md SW-RAID die Parity falsch geschrieben, werden die Daten nur in dem Fall korrupt, wenn dann auch in dem betroffenen Bereich ein Lesefehler passiert und Daten rekonstruiert werden müssen, was ja nun auch nicht so oft auftritt. Die RAM Fehler haben da also weniger gravierende Auswirkungen, auch wenn sie ebenfalls das Filesystem korrumpieren können, wenn Metadaten betroffen sind und in jedem Fall können die Nutzerdaten unbemerkt korrupt sein, wenn diese Veränderung eben vor dem Schreiben im RAM passiert ist, nur wiegt man sich eben nicht in einer falschen Sicherheit.
Man sollte es mit Matt Ahren halten, einem der Mitentwickler von ZFS und der rat dazu zu aller erst einmal ECC RAM und natürlich ein passendes System welches dieses auch unterstützt zu verwenden, wenn man seine Daten liebt:
I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.
Besonders gerne missverstanden wird übrigens dieser erste Teil seines Posts aus dem das Zitat stammt:
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM.
Die eigentliche Aussage des Satzes habe ich mal hervorgehoben, aber weil eben Filesysteme wie NTFS oder ext gerne auf Desktops ohne ECC genutzt werden, versuchen viele darauf abzuleiten man könnte dies auch genauso gut mit ZFS machen, weil ja nichts bei ZFS speziell nach ECC RAM verlangt was es bei anderen Filesystemen nicht auch tun würde. Richtig ist aber und das wird ja auch im Satz "if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data" klar, dass kein System ohne ECC RAM sicher für die Daten ist und man beim ECC RAM eben anfängt, dann erst lohnt es überhaupt erst sich um Prüfsummen Gedanken zu machen aber eben nicht umgekehrt. Ohne ECC RAM ist es dann auch egal ob man ein Filesystem mit Prüfsummen hat oder nicht.
Das der erste Teil "There's nothing special about ZFS that requires/encourages the use of ECC RAM" so nicht ganz stimmt, habe ich ja schon erklärt, aber er wird sein Baby nicht schlechtreden und der Verbreitung im Wege stehen wollen. Außerdem ist es im globalen Kontext, dass eben ohne ECC RAM die Daten sowieso immer gefährdet sind, ja auch egal ob sie nun mehr oder weniger in Gefahr geraten.
Wenn Du Dir Gedanken um BTRFS machst, denn erwartest Du also vermutlich mehr Schutz vor Silent Data Corruption als der gewöhnlich Heimanwender und Fertig-NAS Kunde, der auch mit dem von Consumer HW üblichen Sicherheitsniveau zufrieden ist. RAM passieren, aber sie kommen nicht dauernd und überall vor, sonst würde auch kein Mensch solche NAS kaufen. Consumer HW soll billig sein und meistens bei den meisten fehlerfrei laufen, solange das gegen ist, wird kein Cent für mehr Schutz vor Fehlern ausgegeben. Das tun die NAS, aber mehr Sicherheit durch BTRFS zu versprechen ohne ECC RAM einzusetzen, was gerade beim DS415+ mit seinem Atom C2538 nur einen 9. RAM Chip und ein paar Verbindungen auf dem Mainboard kosten würde, ist mit Verlaub schwerste Kundenverarschung von den NAS Herstellern.
Wenn Du wirklich Sicherheit vor Silent-Data-Corruption willst, dann nimm einen echten Server mit ECC-RAM, für solche HW wurden auch die Filesysteme wie ZFS und BTRFS entwickelt, weshalb sie auch ihre Datenstrukturen im RAM nicht schützen, nur leider hat man darauf verzichtet diese wirklich als technische Voraussetzung zu erklären, wohl um die Verbreitung zu beschleunigen. Diese Filesystem sind für Pentabytestorages entwickelt, die haben auch nicht einmal ein Recoverytool, weil man bei Produktionssystemen eben kein Recovery probiert, wenn mal der schlimmste Fall eintritt. Da zählt für den Techniker nur dem Chef sagen zu können, wann das System wieder am laufen ist und bei einem Recoveryversuch könnte er das nicht, er wüsste ja nicht ob es gut ausgeht. Also werden da in jedem Fall die Backups zurückgespielt, da weiß man recht genau wie lange es dauert, der Chef schluckt dann wenn er hört wie lange es dauert, aber wenn es nach der angegebenen Zeit oder besser kurz vorher wieder läuft, ist alles gut. Klappt es nicht, ist K*cke am dampfen, also riskiert niemand Zeit mit ungewissen Dingen zu verschwenden, daher gibt es keine Recoverytools, die braucht die Zielgruppe nicht und die Heimanwender mit ihren winzigen 10 oder 20TB Storages brauchen solche Filesysteme nicht.
