Crucial SSD - Oberflächenanalyse Meldet 5x E/A Gerätefehler

highks schrieb:

Also aus der Tatsache, dass Acronis wegen zwei EA Lesefehlern einen Fehler meldet, würde ich jetzt nicht unbedingt schließen, dass die SSD definitiv defekt ist. Wenn da ein oder zwei Flash Zellen kaputt gegangen sind, ist zwar jetzt ein Lesefehler da, aber eine SSD hat genug Reservezellen, um diese ein oder zwei Zellen zu ersetzen.
Das macht natürlich die Daten in diesen Zellen nicht wieder lesbar, aber die SSD an sich muss noch lange nicht kaputt sein.

Zum Vergrößern anklicken....

Die Frage ist, wenn die SSD das selbst managt sollte doch der nicht lesbare Bereich Software/Controllerintern entfernt werden und somit auch für Acronis unsichtbar sein oder? Dies ist aber nicht der Fall. Toolhouse meldet ganz klar 5 Lesefehler und auch Acronis meldet Lesefehler...

Einige Beiträge habe ich nur überflogen, aber diese üblichen HDD Tools zum Oberflächencheck sind bei SSDs relativ unsinnig, weil sie stur die LBAs prüfen und die sind bei SSDs nicht immer auf Flash Adressen gemappt. Auch Klonprogramme arbeiten meist so, dass da einfach alle LBAs gelesen werden wenn man ein Image zieht, also auch die nicht gemappten LBAs. Die Lesefehler sind offenbar Fehler in der Mappingtabelle sein, die aber so lange kein Problem sind, wie nicht darauf zugegriffen wird. Windows greift normalerweise ja nur immer auf LBAs zu, die es vorher auch beschrieben hat und daher spielen die im Alltag keine Rolle, da hat der Support von Crucial komplett recht.

Deine SSD hat aber schon einen defekten Block, das ist auch kein Beinbruch und kann alleine wegen der 18 unerwarteten Stromausfälle passiert sein, denn ein unerwarteter Stromausfall ist ein Risiko für jede SSD die keine Pufferkondensatoren hat. Das ein Block ausgefallen ist, sieht man am Rohwert von 05, der 0x100 = 4096 ist und da die Angabe in Sektoren ist, also je 512 Byte, entsprecht das 2MB, genau der Größe eines Blocks bei den NANDs der SSD. Da NANDs ja immer blockweise gelöscht werden, wird bei jedem Fehler immer auch ein ganze Block ausrangiert. Bei einer HDD würde man bei 4096 ausrangierten Block die Platte als fast Tod ansehen, bei einer SSD ist das nicht, es waren alleine schon ab Werk 83 defekte Blöcke in den NANDs gefunden worden, was sogar sehr wenig für eine 256GB SSD ist.

Du kannst ein Secure Erase machen (das löscht alle Daten, aber wenn das sowieso nicht die Windows SSD ist, reicht es die vorher einfach zu kompieren), Du kannst auch einfach die ganze unbelegten LBAs beschreiben lassen, z.B. mit h2testw, dann sollte beim Beschreiben die Verknüpfung des LBAs auf eine korrekte Flashadresse erfolgen. Es kann auch sein, dass die Fehler nur aus der Metadaten des Filesystems stammen ($BadClus), die klonst Du dann meist mit und hast diese Information dann wieder nach dem Zurückschreiben auch auf einer heilen Platte (SSD oder HDD). Daher muss man da aufpassen, was die Programme genau machen und welches Rolle die Metadaten von NTFS da genau spielen, wenn wenn da Sektoren als schlecht markiert sind und dies berücksichtigt wird, bekommst Du diese Fehler immer angezeigt, auch wenn sie gar nicht da sind.

max0005 schrieb:

Die Frage ist, wenn die SSD das selbst managt sollte doch der nicht lesbare Bereich Software/Controllerintern entfernt werden und somit auch für Acronis unsichtbar sein oder? Dies ist aber nicht der Fall. Toolhouse meldet ganz klar 5 Lesefehler und auch Acronis meldet Lesefehler...

Zum Vergrößern anklicken....

Ich bin mir jetzt auch nicht ganz sicher, ob eine SSD das tun kann oder sollte, so lange noch Daten in einem Bereich gespeichert sind. Bei Festplatten ist es jedenfalls so, dass ein schwebender Sektor durchaus Lesefehler verursachen kann - aber nachdem man die Platte einmal komplett formatiert hat, sind die schwebenden Sektoren entweder verschwunden, oder als defekt aussortiert. Danach ist die Platte dann u.U. wieder voll einsatzfähig.
Das nützt natürlich für die eine Datei mit dem Lesefehler nichts, die ist und bleibt kaputt, aber die Platte selbst geht eigentlich noch gut zu nutzen (nicht immer, aber manchmal, so lange keine neuen Fehler dazu kommen)

Ich denke mir eben, dass eine SSD einen unlesbaren Block ebenfalls nicht sofort eigenständig aussortiert, so lange darauf noch Daten gespeichert sind. Dazu müsste man dann erst eine komplette Formatierung oder ein Secure Erase durchführen, dann werden die kaputten Blöcke erst aussortiert, sodass dann auch ein Programm wie Acronis keine Lesefehler mehr feststellt.

Jede SSD hat mindestens so viele GiB NAND-Kapazität wie GB Nutzkapazität, also mindestens etwa 7% mehr. Ein Teil davon geht für Verwaltungsdaten und ggf. für eine zusätzliche ECC drauf, aber was wo steht, weiß man nicht und das spielt auch keine Rolle. Auf Flashadressen die keinem LBA zugeordnet sind, also z.B. zu Reserve oder Free Area gehören, kann man sowieso nicht zugreifen. Dazu müsste man entweder die FW Manipulieren oder die NAND Chips auflöten und auslesen. Die Fehler kommen also nicht davon, dass da etwas aus dem nicht lesbaren Bereich ausgelesen wird, da das eben kein fixer NAND Bereich ist.

Mein Ansatz wäre:
*Backup der Daten
*Auslesen der Smart Werte. Die Werte dokumentieren.
*Secure Erase der SSD.
*SSD mit Schreibzugriffen belasten. Anzahl der geschriebenen GB deutlich größer als die Größe der SSD. Alles sollte mal beschrieben werden. Bei Sandforce basierten SSD keine Daten verwenden, die leicht zu komprimieren sind.
*Smart Werte erneut auslesen. Kritische Werte vergleichen.
*Falls Auffälligkeiten auftreten -> SSD umtauschen
*Ansonsten Backup wieder einspielen.

Zum Beschreiben für den Test einfach h2testw nehmen und ein Secure Erease ist nicht unbedingt nötig, es reicht auch ein Formatieren aus. Man kann auch einfach die bestehenden Partitionen mit h2testw fast vollschreiben, auch wenn heise davor warnt. Dann lässt man einfach ein paar wenig GB frei. wählt also etwas weniger aus als frei ist, damit es keine Probleme mit Windows gibt.

Holt schrieb:

.. ein Secure Erease ist nicht unbedingt nötig, ...

Zum Vergrößern anklicken....

Ein Secure Erase dürfte die SSD dazu bringen ihre Mapping Tabellen einmal vollständig neu zu erstellen und somit eine mögliche Fehlerquelle zu entfernen. Dieses dürfte ein Format des Datenträgers nicht auslösen.

Ein Format löst es nur aus, wenn dabei auch getrimmt wird, obwohl da nicht die ganze Tabelle gelöscht wird, sondern natürlich nur die getrimmten LBAs. Aber spätestens das neu Beschreiben dürfte dann so gut wie die ganze Tabelle erneuern und damit auch fehlerhafte Einträge beseitigen, sofern diese nicht ausgerechnet außerhalb der Partition liegen.

Holt schrieb:

Ein Format löst es nur aus, wenn dabei auch getrimmt wird, obwohl da nicht die ganze Tabelle gelöscht wird, sondern natürlich nur die getrimmten LBAs. Aber spätestens das neu Beschreiben dürfte dann so gut wie die ganze Tabelle erneuern und damit auch fehlerhafte Einträge beseitigen, sofern diese nicht ausgerechnet außerhalb der Partition liegen.

Zum Vergrößern anklicken....

Oder die Firmware verwirren weil die Einträge im mehreren Tabellen geführt werden. Leere Blöcke, belegte Blöcke und evtl. zu trimmende Blöcke wären mögliche Tabellen und wenn sich ein Block davon im mehr als einer Tabelle befindet könnte es zu undefinierten Verhalten führen.

Also ich glaube, dass hat einen anderen Grund und den erfährt man in Anands Review der Micron M500DC:

DataSAFE ensures that all data, read or written, is intact. When writing data, Micron not only writes the data from the host to the NAND but also the metadata associated with the data (i.e. its logical block address/LBA). When the host then requests the data to be read from the drive, the LBA of the data is first compared against the value in the L2P table (logical to physical -- Micron's name for the NAND mapping table) before sending the data to the host. This ensures that the data that is being read from the NAND is in fact the same data that the host requested. If the LBA values of the NAND and L2P table are different, then the drive will have to rely on ECC or RAIN to recover the correct data.

Zum Vergrößern anklicken....

Den letzten Teil, also das Micron die ECC nur prüft wenn der LBA nicht stimmt, will ich mal nicht hoffen ,denn das wäre hoch riskant, aber dass die LBAs bei den Daten stehen müssen, hatte ich ja schon oft überlegt. Nur so kann die m4 Power Cycle Wiederbelebung funktionieren, bei der der Controller dann angeregt wird die Mappingtabelle (LBAs auf NAND Adresssen, auch Indirection Table oder hier L2p Table genannt) aufgrund dieser überall verteilen Daten zu korrigieren bzw. neu aufzubauen.

Nimmt man dann noch die Power-Loss Protection dazu:

While both Micron's client and enterprise SSDs feature power loss protection, there is a difference between them. The enterprise drives features more rigid tantalum capacitors that provide a higher capacitance compared to the standard capacitors used in the client drives. The higher capacitance ensures that absolutely no data is lost during a power loss, whereas there is still a small risk of data loss in client drives. I believe the difference is that the capacitors in client drives only provide enough capacitance to flush the NAND mapping table (or L2P table as Micron calls it) to the NAND, while the enterprise solution guarantees that in addition to the NAND mapping table, all write requests in process will also be completed.

Zum Vergrößern anklicken....

Das klingt durchaus sehr plausibel, denn wenn die normalen Kondensatoren der Crucial SSDs auch für die ganzen Nutzerdaten reichen würden, musste man bei der Enterprise Version ja keine Tantal Kondensatoren verbauen. Korrupte Mappingtabellen aufgrund unerwarteter Stromausfälle sind ja immer schon ein großes Problem bei SSDs gewesen und auch in diesem Test dazu haben nur die beiden Intel SSD bestanden, aber nicht weil sie von Intel sind, sondern weil es die einzigen im Test mit Stützkondensatoren waren.

Nimmt man nun an, dass die Mappingtabelle bei einem unerwarteten Stromausfall mit der Ladung der Kondensatoren noch aktualisiert in die NANDs geschrieben werden konnte, aber eben nicht mehr die Nutzerdaten, dann gäbe es einen Fehler beim Abgleich mit dem LBA der zusammen mit den Daten im NAND steht und sehr wahrscheinlich werden da keine Daten in der Page stehen, die sollte ja erst geschrieben werden, was der Stromausfall verhindert hat. Was macht der FW Entwickler nun, wenn die LBA gemappt ist, aber die Daten dort nicht zu der LBA gehören? Die kann er ja nicht einfach zurückgeben, dann wären die Dateien ja korrumpiert, also wird er wohl so reagieren wie es bei einer HDD ist, die die Daten eines Sektors nicht lesen kann und einen Lesefehler melden, was dann hier wohl 5x der Fall ist. Mit einer Oberfläschenanalyse hat das aber nichts zu tun und wenn sonst keine Fehler auftreten, ist das auch egal. Der Fehler wird wie bei einer HDD mit einem schwebenden Sektor einfach dann korrigiert, wenn die Daten neu geschrieben werden und das kann man mit h2testw für praktisch den ganzen nutzbaren Bereich erreichen.

So, habe jetzt mit Secure Erase die SSD gelöscht. Das Protokoll sagt 61665 Fehler (Dateien die nicht gelöscht werden können).

Was soll ich nun tun? Ich habe auch den empfohlenen Garbage Collection durchgeführt ( SSD ohne SATA Kabel nur mit Strom verbinden und für 6-8h eingeschaltet lassen. Dann bereinigt der Controller Daten/ Fragmente.. tralala ).

Was für ein Secure Erease hast Du genommen? Wenn wir hier von Secure Erease reden, meinen wie den ATA Befehl der den Controller der SSD dazu auffordert alle Daten zu löschen und nicht irgendein Wiper Tool. Der Controller kennt keine Dateien, die gibt es nur auf der Filesystemebene, also im Betriebssystem.

Poste am Besten noch mal einen aktuellen Screenshot von CrystalDiskInfo.

Auch eine SSD darf keine Lesefehler liefern. Wenn sie das tut, dann stimmt einfach was nicht mit dem Ding.

Bei den Crucial SSDs scheint es offenbar vorzukommen, dass diese mit Lesefehler reagieren, wenn die Mappingtabelle Fehler aufweist. Das ist aber eine ganz andere Geschichte wie Lesefehler bei HDDs, die ja meist aufgrund von Oberflächenfehler und damit Beschädigungen auftreten. Ein korrekt ausgeführtes Secure Erease Kommando an den Controller sollte diese beheben.

So, Crucial hat sich Erbamt und ich bekomme eine neue SSD. Ich habe meine defekt am Freitag nach Glasgow geschickt.

Zusammen gefasst: Lesefehler sind NICHT normal! Danke für eure Hilfe.