wieso ist dann ECC Korrektur überhaupt noch relevant bei ZFS oder btrfs/ReFS..im privaten Segment
Bei einem Filesystem ist das etwas anderes als bei RAM, aber HDDs (und auch SSDs) haben am Ende jedes Sektors eine eigene ECC und schicken keine falschen Daten, sondern einen Lesefehler, wenn sie es trotz wiederholter Versuche nicht schaffen die Daten korrekt zu lesen. Es liegt dann an der Anwendung die den Lesebefehl geschickt hat, was sie daraus macht, aber wenn der Lesebefehl von einer RAID Lösung (SW-oder HW RAID, aber kein RAID 0) kommt, dann wird das RAID die Daten von den anderen Platten und der Parität wiederherstellen, den problematischen Sektor überschreiben und die korrekten Daten nach oben an die Anwendung weiterreichen. Die zusätzliche ECC im Filesystem sichert dann nur noch dagegen ab, dass die RAID Lösung da einen Fehler macht, etwa durch einen Bug in der FW eines HW RAID Controllers.
On-Die-ECC bei DDR5 RAM wirkt als würde man dies nur einsetzen, weil vllt. anders nicht mehr stabil eine Übertragung umsetzbar ist, bei derartigen hohen Takt.
Nein, nicht die Übertragung, die wird schon seit DDR4 mit einer CRC abgesichert, eben mit dem Zeitverlust durch Wiederholung der Übertragung bei Fehlern, sondern wohl wegen der kleineren Strukturen der DRAM Zellen, die offenbar nun so problematisch geworden sind, dass es eben zu oft zu Fehlern kommt und man daher On-Die-ECC eingeführt hat.
Ich Hoffe, dass das auch eine Geschichte ist, die unabhängig vom CPU/Mainboard Chipsatz stattfindet
Ja, deswegen heißt es ja On-Die-ECC, weil es eben auf dem Die stattfindet und nicht im RAM Controller, der bei neueren CPUs schon lange in der CPU sitzt. Der Chipsatz hat damit also nichts zu tun, außer das eben bei Intel geschaut wird welcher Chipsatz vorhanden ist und wenn es der falsche ist, wird die ECC Funktion des RAM Controller eben einfach nicht aktiviert. Genau wie bei anderen Funktionen wie der Aufteilung der 16 PCIe Lanes für die Graka, die auch nur mit dem passenden Chipsatz möglich ist, obwohl diese PCIe Lanes direkt von der CPU kommen und mit dem Chipsatz direkt gar nichts zu tun haben.
abgesehen davon, dass ich auch bei 12gen Celeron/Pentium keine Wiederbelebung zu ECC aktiver Nutzung finde, sind passende 11Gen Xeons nicht erhältlich
Die klassische ECC gibt es ja weiterhin, jetzt wegen der Subchannels sogar mit 80 Bit statt vorher 72 Bit Datenbreite der Module und die wird sicher auch stärker als die On-Die-ECC sein. Stärker bedeutet, dass unerkannte und unkorrigierbare Fehler weniger wahrscheinlich sind und es gibt ja schon heute unterschiedlich starke ECC Implementierungen, von denen die einfachsten bisher nur Singlebitfehler korrigieren können. Keine Ahnung wie stark die On-Die-ECC bei DDR5 so ist, dazu habe ich bisher noch nichts gefunden und natürlich erspart die ECC im RAM Controller die erneute Übertragung bei RAM Fehlern und man erfährt von den Bitfehlern im RAM auch nichts, da diese ECC ja im Die passiert und damit für den Rechner komplett transparent.
Persönlich hätte ich bisher auch als nächsten Rechner oder Heimserver nur an einen Xeon gedacht, aber mit On-Die-ECC DDR5 könnte ich auch leben, da hat man ja einmal die ECC im Die gegen Bitfehler im RAM und dann die CRC bei der Übertragung gegen Übertragungsfehler. Genau wie im Beispiel der ECC in Filesystemen mit denen wir angefangen haben, hast Du damit nur noch das Risiko ob das auch auf beiden Seiten, also nicht nur beim RAM Controller sondern auch im RAM selbst, korrekt implementiert ist. Bei der klassischen ECC musst Du hingegen nur darauf vertrauen das der RAM Controller diese korrekt ausführt und bei den Xeons würde ich da viel mehr Vertrauen in Intel als jeden einzelnen der Vielzahl von Anbietern von RAM Riegeln haben. Genau wie man bei ZFS, btrfs, ReFS. etc. eben nur darauf vertrauen muss, dass diese die ECC korrekt handhaben und nicht auch jede HDD und der ggf. vorhanden RAID Controller, wobei SAS Lösungen da besonders kritisch sind, da die HW RAID Controller SAS Platten gerne auf 520/528 Byte pro Sektor formatieren um dann in den zusätzlichen Bytes eine eigene ECC abzulegen und dann lassen sie sich beim Lesen direkt die Rohdaten (also ohne deren eigene ECC ) von der Platte geben. Dies vermeiden Verzögerungen durch Versuche der Platten die Daten durch wiederholte Versuche doch noch korrekt zu lesen, der RAID Controllern kann bei Lesefehlern sofort anfangen die Daten der anderen Platten und die Pariy zu lesen um die korrekten Daten wiederherzustellen, aber wehe wenn da ein Bug in dessen FW ist und genau dagegen sichern dann Filesysteme mit eigener ECC ab. Oder eben bei SATA Platten ein Bug in der FW der dafür sorgt, dass doch korrupte Daten geliefert werden, aber das war meines Wissens zuletzt vor mehr als 10 Jahren bei den F4EG der Fall, wo
der Cacheinhalt verändert werden konnte, wenn ein ATA IDENTIFY DEVICE Befehl geschickt wurde.
warum wird dann auf On-Die-ECC +ECC Wert gelegt, ersteres wäre dann ja überflüssig.
Wer legt darauf Wert? Bisher gibt es nur Alder Lake und davon auch nur die Consumer CPU (und auch nur die K Modelle) ohne ECC Funktion im RAM Controller und damit auch noch gar keine DDR5 ECC RAMs zu kaufen. Ob diese DDR5 RAM Riegel dann auch eine On-Die-ECC haben werden, ist also noch offen. Aber selbst wenn, die CRC hat halt den Nachteil, dass man bei Fehlern die Übertragung wiederholen muss, was ein Performancenachteil ist, erst recht wenn viele Wiederholungen nötig sind bis die Daten korrekt übertragen wurden.