Gerk schrieb:
Weil ich seit etwa 10 Jahren nur noch ECC-RAM habe.
Und hoffentlich auch ein System wo der Rest diese Funktion auch unterstützt, also ein passendes Board und die passende CPU dazu, denn sonst hänge die zusätzlichen Bit der ECC RAM Riegel ja nur unnütz in der Luft. Ein ECC RAM Riegel ohne passendes System ist nicht besser als ein normaler RAM Riegel und kann alleine keine RAM Fehler verhindern, der hat eben einfach nur 72 statt 64 Bit Datenbreite.
Gerk schrieb:
Wenn man eine SSD mit H2testw voll schreibt, alles fehlerfrei ist, man die Daten drauf lässt, monatlich, zuerst fehlerfrei, prüft und ab etwa 18 Monaten immer die gleichen Dateien an der gleichen Stelle Fehler haben, dann soll das Deiner Meinung nach am RAM liegen?
Da Du mit konkreten Informationen sehr sparsam bist und Dein Beiträge mich an jemande erinnern der nur mit komischen Kommentaren aufgefallen ist, habe ich keine Meinung dazu.
Welche SSD ist es denn überhaupt? Wie ist die angeschlossen, über USB oder direkt über SATA? Was für ein Mainboard ist es? Die Controller haben auch RAM, da kann es auch zu RAM Fehlern und damit Datenkorruption kommen, wenn die SSD übr USB angeschlossen wird, dann wären der USB Host Controller und der USB-SATA Bridgechip mögliche Fehlerquellen, sonst der SATA Host Controller, dazu jeweils der Controller und dessen Cache auf der SSD selbst, wenn sie keine internal Data Path Protection hat.
Gerk schrieb:
Die SSD hatte bisher 9 unkorrigierbare ECC-Fehler, 3 benutzte Reserveblöcke und keine einzige Meldung von Windows - eventuell im Ereignisprotokoll, aber welcher User sieht da ohne Kenntnisse hin.
Da kann auch die Ursache liegen, denn es hängt von der FW ab, da gab es genug Probleme bei SSDs in der Vergangenheit. Diese sollten nicht zu Datenkorruption führen, aber 100%ig sicher kann man da nicht sein und bei bestimmten Modellen würde es mich weit weniger wundern als bei anderen. Wenn es unter Linux ist (da läuft h2testw aber nicht), so sind dort auch Bugs im kernel in dem Zusammenhang aufgefallen die zu Datenkorruption führen, u.a. gab es Ärger mit Queued TRIM, aber auch bei der FW bestimmter SSDs.
Gerk schrieb:
Hier noch ein paar SMART-Werte:
178 Used_Rsvd_Blk_Cnt_Chip 0x0003 100 100 000 Pre-fail Always - 3
181 Program_Fail_Cnt_Total 0x0003 100 100 000 Pre-fail Always - 0
182 Erase_Fail_Count_Total 0x0003 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0002 100 100 000 Old_age Always - 9
192 Power-Off_Retract_Count 0x0003 100 100 000 Pre-fail Always - 148
196 Reallocated_Event_Count 0x0003 100 100 000 Pre-fail Always - 9
Solche Ausschnitte wie in der Peepshow mag ich gar nicht, zeige alle Attribute, oder was willst Du verbergen was die Lösung aufzeigen würde? Solche Ratespiele mache ich jedenfalls nicht mit.
Gerk schrieb:
Und jetzt komm mir bloß nicht mit Power-Off.
Warum nicht? Unerwartete Spannungsabfälle sind Gift für SSDs, wenn diese die Mappingtabelle dann nach einem Schreibvorgang nicht zurückschreiben konnten, kommt es immer wieder zu Problemen. Der 8MB Bug der ersten Intel SSDs, der bei der 320er als solche aufgefallen aber auch bei den Vorgängern vorhanden war, kommt daher ebenso wie Probleme bei den Crucial SSD mit Marvell Controllern, wenn diese verschinden und dann nach Anwendung der
Power Cycle Wiederbelebung wieder funktionieren. Dies sind nämlich Zeichen eines Sicherheitsmechanismus der die Konsistenz der Mappingtabelle und damit der Daten prüft und bei Probleme eben lieber den Zugriff auf die Daten verhindert als Datenkorruption erlaubt. Da es dann meist auch zu Garantiefällen kommt, dürften einige SSD Hersteller versucht sein, lieber die Datenkorruption zu akzeptieren und letztlich dürfte es den meisten Heimanwendern auch lieber sein, dann noch an ihre Daten zu kommen als die SSD einschicken zu müssen.
)Der neue Ansatz soll andere Teile des Kernels und letztlich auch Anwendungen ermöglichen, einige Fehlersituationen galanter abzufangen. Details hierzu erläutert ein LWN.net-Artikel."
