Crucial M4: Lesefehler durch Speicherchipdefekt?

[dnaxx]

Hallo,

Ich verwende seit ende Juni eine Crucial M4 512GB SSD, 000F Firmware (Betriebsstunden laut Crystal Disk Info ca. 448) und war bis heute morgen sehr zufrieden damit. Von den 512GB sind noch in etwa 90 GB frei. Die Schreibzugriffe sind bei mir sicher etwas über dem durchschnittliche User da ich VMWare Maschinen verwende aber selten mit Ruhezustand oder ähnlichen Schreibintensiven Operationen.

Heute konnten dann plötzlich verschiedene Dateien nicht mehr gelesen werden (Systemdateien und andere; manche davon habe ich sicher schon einige Zeit nicht mehr geöffnet gehabt). c't Desinfect habe ich ausgeführt aber ohne Virusmeldung.

Im Moment lasse ich mal chkdsk über die SSD laufen was allerdings wegen einiger VMWare Disks ziemlich lange dauert da diese bis zu 100GB groß sind (bzw. habe ich den Eindruck das chkdsk bereits hängt; mal schauen ob sich in den nächsten Stunden was tut).

Wie kann es zu so einem Fehler kommen? Kann es sein, dass ein Speicherbaustein mit Daten defekt wurde? Und, würdet Ihr die SSD zum Händler zwecks Austausch zurückschicken?

Grüße

 

[meckswell]

Den Ram kannst mit memtest86+ testen [von Stick oder CD starten]. Die Smart Werte der SSD und evtl HDDs mit Crystal Disk Info anschauen. CRC Fehler z.b. deuten auf Probleme mit einem Satakabel hin, die Kabel auch mal auf festen Sitz prüfen.

 

[Holt]

Poste bitte mal den Screen von CrystalDiskInfo, aber bitte so, dass alle Attribute und auch die Hex-Werte vollständig sichtbar sind.

 

[Asinuss]

Versuche erstmal ein anderes SATA Kabel zu nehmen

 

[dnaxx]

Die SSD sitzt in einem Lenovo w530 Notebook und das ziemlich fest. Ich habe sie zu Testzwecken auch an ein anderes Gerät angeschlossen mit den selben Problemen.

Der Screenshot kommt etwas später wenn chkdisk fertig ist.

 

[3murmeln]

Was für Dateien sind denn da genau kaputt gegangen - die Systemdateien des virtuellen Systems innerhalb der VMWare oder auf dem Hostbetriebssystem?
Wenn 1steres der Fall, kann es auch durchaus sein, dass VMWare das Image geschrottet hat...

 

[dnaxx]

Dateien auf der SSD (inklusive einiger großer VMWare Disks). Große Files sind nicht komplett kaputt, sondern nur teilweise (früher bei HDs hätte ich Sektorweise gesagt). Die Fehler sehen insgesamt so aus wie früher bei Festplatten wenn einige Sektoren durch einen Schlag oder ähnliches defekt wurden - daher auch meine Theorie mit einem defekten Speicherbaustein.

 

[ottkog]

Hallo, wenn noch Garantie Kopie machen und zum Händler zurück sonst zu Crucial einschicken die haben ein sehr freundlichen Support.

 

[Simpson474]

Neben der SSD könnte es theoretisch noch der RAM bzw. die CPU sein - hast du übertaktet?

 

[digitalangel18]

Screenshot der Smart Werte, z.B. mit CrystalDiskInfo, wäre sinnvoll

 

[Holt]

Den Screenshot hat er schon versprochen, sobald chkdsk durch ist.

dnaxx, Du solltest auch mal mit Memtest86 das RAM testen. Dazu ist unbedingt von CD oder USB-Stick zu booten, es sollten min. 6 PASS abwarten werden und es darf dabei kein Fehler auftreten (also am Besten über Nacht laufen lassen). Gerade wenn große Dateien defekt sind, dann kann schon ein Bit welches zuweilen kippt die Ursache sein.

Sowas hatte ich vor Jahren mal bei einem Pentium 4, auf dem auch immer wieder größere rar Archive defekt erstellt wurden. Dann habe ich die immer zweimal gemacht und ein Programm geschrieben, welches beide verglichen hat und richtig, es war immer wieder das gleiche Bit gekippt. Bei Archiven von etwa 1GB Größe nur ab und an, oft auch garnicht. Der Rechner liegt stabil und problemlos wochenlang am Stück durch. Memtest86 hat nach vielen PASSES dann mal einen Fehler gefunden und dann mal wieder nicht.

 

[dnaxx]

Anbei der Screenshot.

 

[Simpson474]

Ich weiß nicht, wie Crucial das SMART Attribute 0xBB interpretiert - aber es klingt nicht wirklich gut und bei den Screenshots im Internet von anderen M4 steht der Wert eigentlich immer auf 0.

EDIT: Wenn ich die Daten deuten würde, so klingt das entweder stark nach einem Firmwarebug oder exakt deiner Vermutung, dass ein Flash-Block während dem Betrieb ausgefallen ist. Die SSD prüft höchstwahrscheinlich beim Schreiben in einem Block, ob dieser intakt ist indem die Daten zurückgelesen werden und über den ECC-Mechanismus ein Qualitätsindikator für den Block gebildet wird. Dieser Qualitätsindikator scheint beim Schreiben noch einen guten Wert geliefert zu haben (Attribute "Schreibfehlerrate" und "Programmfehler" sind 0), dennoch ist beim Lesen der ECC-Mechanismus nicht mehr in der Lage, die Fehler zu korrigieren (Attribute "Leserfehlerrate" und "Gemeldete unkorrigierbare Fehler" größer 0). Wahrscheinlich würde die SSD beim einem Secure Erase und anschließendem neu beschreiben die entsprechenden Blöcke ausmustern (Attribut "Wachsende fehlerhafte Blocks" würde ansteigen) - ist halt die Frage ob wirklich nur ein Block ausgefallen ist oder ob z.B. eine Lötstelle nicht ganz sauber ist. Fehlerhafte Blöcke bei NAND sind eigentlich nichts besonderes und bereits in der Produktion wurden bei deiner SSD 147 fehlerhafte Blöcke aussortiert - allerdings sollte der Tod der funktionsfähigen Blöcke schleichend kommen und nicht so abrupt, so dass die Fehlerkorrektur beim nächsten Lesen schon nichts mehr korrigieren kann.

 

[dnaxx]

chkdsk ist erfolgreich durchgelaufen und hat auch die defekten Dateien reparieren können (soweit ich dass bis jetzt beurteilen kann). Allerdings treten beim Schreiben ständig neue Fehler auf. Also die M4 schicke ich am Montag auf jeden Fall auf Garantie ein.

 

[Holt]

Das die Daten nach den Schreiben nochmal gelesen werden, kann ich mir kaum vorstellen, das wäre schon arg langsam. Da die m4 ja sowieso keine so hohe Schreibrate bietet, wäre es aber auch nicht ganz auszuschließen. Die Frage ist natürlich, warum solche Lesefehler nicht auch bewirken, dass ein Block danach ausrangiert wird und wieso die Hex-Werte von BB und 01 so stark abweichen, aber auch nicht ganze Vielfache voneinander sind.

Ergänzung (25. August 2012)

Im Crucial Forum ist auch so ein Fall.

 

[dnaxx]

@Holt: Interessant. Und auch ziemlich zur gleichen Zeit (was aber wahrscheinlich ein Zufall ist)

 

[Holt]

Vor allem sind beides 512GB Modelle. Vielleicht ist das ein Problem welches sich nur auf Modelle mit 512GB bezieht.

 

[Simpson474]

Das die Daten nach den Schreiben nochmal gelesen werden, kann ich mir kaum vorstellen, das wäre schon arg langsam.

Recht viel andere Möglichkeiten dürften sich bei NAND-Flash nicht bieten, fehlerhafte Blöcke zu erkennen. Möglich wäre noch, dass fest vom schleichenden Tod der Flash-Zellen ausgegangen wird und dann würde es theoretisch reichen, beim nächsten Lesen der Daten die Qualität dieser über die Fehlerkorrektur zu beurteilen - praktisch kann dann aber genau das passieren, was beim TE geschehen ist. Das auch ältere Dateien betroffen sind kann mit dem Wear-Leveling der SSDs zusammenhängen - irgendwann müssen auch Daten von eigentlich unveränderten NAND-Blöcken verschoben werden, da diese Blöcke ansonsten viel weniger Löschzyklen bekommen würden.

EDIT: Hier ist auch eine 128GB Version davon betroffen mit ähnlichen Symptomen und ähnlichen SMART Werten.

 

[Holt]

Simpson474, die hat aber auch Schreib- und Löschfehler (wenn auch keine Reallocated Sektoren, was man erwarten sollte) und das haben die beiden anderen nicht.

 

[dnaxx]

Ich habe mir eine neue M4 gekauft während die Reklamation der Alten läuft. Falls es jemanden interessiert, hier die Daten der neuen SSD (nach dem Klonen der alten HD auf die SSD).