Ist eigentlich nebensächlich, wenn ... kein Mensch groß Geräte an den Chipsätz klemmt bei derartigen Boards und C) die Last dann über die PCIe Lanes verteilt werden würde. -> kurzum, auch beim X99 wird idR der noch schmalere DMI nicht zum direkten Falschenhals. Allerbestenfalls wenn man die SATA Ports mit SSDs voll bestückt, entsprechende Raidlevel fährt
DMI2 bedeutet real so 1600MB/s und bei 10 SATA Ports müssen nur mehr als 3 schnelle SSDs im RAID 0 sein die einzuschränken oder 8 schnelle 3.5" HDDs, schaffen die schnellsten schon über 220MB/s auf den äußeren Spuren. Dabei darf nichts auf den USB Ports oder von Controllern an den PCIe Lanes des Chipsatzes übertragen werde, also so üppig ist bei dem X99 die DMI2 Bandbreite nicht und nicht jeder hängt alles I/O in Form von Extra Controllern an die PCIe Lanes der CPU. Aber das ist ja hier egal, denn M.2 SSDs sollte man beim X99 auf jeden Fall mit Lanes der CPU versorgen.
Btrfs schützt mich nicht vor Speicherfehlern, ob mit oder ohne ECC.
Nein, aber mit Bitfehlern kann Dir btfs wie jedes andere Dateisystem korrupt werden und es schützt auch nicht davor, dass die Daten nicht durch die Bitfehler unbemerkt schon korrupt abgespeichert wurden oder schlimmer noch kaputt korrigiert werden. Das kann bei ZFS und vermutlich auch bei btrfs eben passieren, wenn das Filesystem aufgrund von RAM Fehlers auf eine Inkonsistenz trifft und diese für eine Zeichen korrupte Daten hält, woraufhin die Daten "korrigiert" und dann korrupt werden. Eine normalen ext Filesystem auf einem md raid würde das nicht machen, da gibt es nur die dann vom RAM Fehler korrumpierten Daten zurück, aber die Daten auf den Platten werden deswegen nicht verändert. Das würde nur passieren, wenn es gleichzeitig einen Lesefehler gibt und daher die Daten mit hilfe der Parity rekonstruiert werden müssen und dann auch auf die betroffene HDD geschrieben werden.
Liegen Metadaten des Filesystems in einem RAM.Bereich wo es zu RAM Fehlern kommt, dann ist kein Fileystem davor geschützt korrupte Daten zu liefern und meist wird dann auch noch das ganze Filesystem korrupt werden Vor RAM Fehlern schützt aber nur ECC RAM mit entsprechendem Board und passender CPU, also Xeon statt i5/i7 und bei S. 115x ein C2xx Chipsatz. Beim S. 2011-3 können ja wohl einige ASRock X99er Board mit einem Xeon E5 drin dann auch ECC unterstützen, der X99 scheint es also nicht zu verhindern.
Zum Erkennen von Fehlern sind die Checksummen, zum Beheben die Backups.
Wenn dann mal der Fehler den die Prüfsumme meldet echt ist und die Daten im Backup noch korrupt sind. Wenn Du Dir Sorgen um Silent-Data-Corruption machst, fange mit ECC RAM an und nicht überlege ob Du noch ein Filesystem mit Prüfsummen draufsetzt, nicht umgekehrt. Genauso rät es auch
Matt Ahren, einer der Mitentwickler von ZFS:
Das einmal geschribene Bits auf der Platte kippen, ist ja nur der eine Part.
Wobei das bei einer HDD kein Thema ist, denn außer man nutzt spezielle Befehle um die Daten roh zu lesen wie es die SAS RAID Controller gerne machen um die TLER zu umgehen, bekommt man diese Daten so nie von der Platte wieder. Diese SAS formatieren dann auch die HDDs auf 520/528 Bytes pro Sektor und schreiben selbst eine Prüfsumme in diese zusätzlichen 8/16 Byte um eben Lesefehler sofort zu erkennen und die Daten anhand der Parity zu rekonstruieren, statt zu warten ob die Platten den Sektor in späteren Versuchen nicht doch noch erfolgreich lesen kann. Das geht bei SATA Platten gar nicht, die liefern einen Lesefehler zurück, wenn die Daten nicht zur ECC passen, die es hinter jedem Sektor gibt. Da bekommt man keine korrupten Daten wieder, außer bei Nutzung von den ATA Streamingbefehlen für Echtzeitvideoaufzeichnung, aber die werden nicht für normale Dateioperationen verwendet.
Das ein Bit auf einer Platte mal kippt passiert durchaus mal, dass es dann aber auch dazu führt das falsche Daten geliefert werden, passiert bei einer SATA Platte normalerweise nie, die Wahrscheinlichkeit das falsche Daten trotzdem zu ECC passen ist extrem gering. Die Übertragung ist mit einer CRC32 pro FIS welcher maximal 8192Byte Nutzdaten enthalten kann, auch praktisch Null, denn eine CRC32 lässt auf 8192 Byte weniger einen Fehler pro 1:10^14 fehlerhafter Übertragungen durch, das sind mehr Daten als das Internet gespeichert hat oder ja an HDD Kapazität produziert wurde!
Bleiben also Lücken nur Fehler aus den internen Datenpfaden der Platten, Consumer HDDs schützen diese ja meist nicht und haben auch oft kein Ende-zu-Ende Fehlerattribut in den S.M.A.R.T. Werten was wenigstens eine Fehlererkennung anzeigt, des Host Controllers oder FW Bugs bei der HDD oder dem Host Controller. Das sind die Fehlerquellen vor denen Dich Prüfsummen im Filesystem wirklich schützen können, aber z.B. ein md RAID mit ext4 drauf eben nicht.
Heist wiederum auch, nicht zwingend ist das, was dort im RAM steht zur Prüfung gegen die Checksumme das, was wirklich auf dem Massenspeicher ist.
Genau da wohnt das Risiko, man hat A ins RAM Geschrieben aber wegen einer Fehler wird dann dort B stehen und immer wieder B ausgelesen. Durch die Prüfsummen wird er Fehler bemerkt und dann beginnt das Unheil, wenn die Korrektur des Fehler beginnt und dann die Daten so anpasst, dass diese dann verändert werden. Das passiert bei einem normalen SW-RAID nicht, ein md SW RAID liest anderes als ZFS eben die Parity bei normalen Lesevorgängen nicht mit und prüft die Daten daher auch nicht gegen die Parity. Deshalb wird bei ZFS mehr gelesen, mehr Daten landen im RAM und damit steigt eben auch das Risiko von RAM Fehler betroffen zu werden, entgegen der Aussage von dem Matt Ahren im Rest des oben zitierten Beitrags. Aber der will auch Werbung für sein Baby machen und die eigentliche Aussage ist nicht wirklich quantitativ sondern qualitativ zu sehen:
Sprich: Hast Du kein ECC RAM kann jedes Filesystem wegen RAM Fehler korrupt werden und eine Abfrage ob das System mit ECC RAM arbeitet und welche ZFS nur für solche System freigibt, ist im Filesystem nicht vorhanden. Wie er seine Aussage danach zusammengefasst hat, habe ich ja oben schon zitiert.
Baut der Hauptspeicher aber Mist, zerlegst du dir im Worst Case ALLES. Inkl. dem Backup.
So ist es und wenn das eine Workstation ist, dann kann es auch leicht sein, dass schon die Daten im RAM Bereich des Programms welches sie schreibt korrupt werden, weil sie gerade in dem Bereich liegen, wo der RAM Fehler ist. Ist es ein Storage Server im Netz, dann kann es schon passieren, wenn sie vom Netzwerktreiber ins RAM geschrieben werden und das Filesystem bekommt sie schon korrupt bevor es sie liest, seine Prüfsumme darüber bildet und alles abspeichert, womit sie scheint korrekt gespeichert sind, nur wurde eben nicht das gespeichert, was über das Netzwerk angekommen ist.
Persönlich würde ich, wenn du schon so eine Kiste fährst, dann nicht am ECC sparen. Der Aufwand, sich dagegen zu schützen ist relativ gering und die Kosten ebenso.
So sehe ich das auch, die Mehrkosten sind im Vergleich bei derartiger HW nicht sehr hoch. Wer ein System haben will welches im Bezug auf stabilen Betrieb und die Sicherheit der Daten vor Korruption mehr leistet als normale Consumer HW, der sollte auch keine normale Consumer HW kaufen, sondern eben Workstation- oder Serverhardware, wobei ein Workstationboard mit Xeon Chipsatz da meist optimal ist, denn Fernwartung braucht man an einer Workstation wo man ja direkt vor dem Rechner arbeitet, i.d.R. eben nicht und die werden auch nicht headless betrieben.
. Wenn genug Geld da ist, kann man sich mit dem Fujitsu C236 für ~150€ ECC auch mal genau überlegen. Was BTRFS ohne RAID und ohne ECC schlechter als ext macht, konnte mir auch noch niemand der vielen Leute hier erklären.
