SSD defekt?

OBrian

Moderation MBDB, ,
Mitglied seit
16.10.2000
Beiträge
17.033
Renomée
267
Standort
NRW
Ich hab seit letztem Jahr (muß noch die Rechnung raussuchen, aber Garantie ist sicher noch drauf) eine Super Talent SSD, genauer gesagt eine 128GB Ultradrive ME (FTM28GX25H), vor längerer Zeit problemlos auf Firmware 1571 gepatcht. Restliches System siehe links.

Vor ca. 1-2 Wochen fing Windows XP an, sporadisch Scandisk beim Booten auszuführen, und hat dann auch immer einiges gefunden an verwaisten Dateifetzen usw., also recht heftige Fehler im Dateisystem. Ich dachte erst, daß käme von einem Crash (es war mal ein Spiel eingefroren und ich mußte mit Knopf rebooten), aber die Scandisk-Vorfälle kamen immer häufiger, dann bei jedem Bootvorgang.

Ich hab dann mal das Trim-Tool von ST ausgeführt, was ich bisher nicht genutzt hatte, und danach schien es etwas besser sein, nach kurzer Zeit fing es aber wieder an. Schließlich fehlten einige Dateien, die ich noch ersetzen konnte (hatte den ganzen SSD-Inhalt auf eine andere HD kopiert), aber schließlich war das Windows so im Eimer, daß es nicht mehr gestartet ist und ich neu installieren mußte.

Bei der Gelegenheit wollte ich die Firmware mal auf den neuesten Stand bringen, also 2030, aber der Updater hat die SSD nicht erkannt, d.h. zwar erst gelistet, nach Auswahl von "1" aber dann nicht als geeignetes Gerät akzeptiert (war aber richtig auf IDE-Modus gestellt). Hat mich gewundert, aber hätte ja auch ein Problem mit dem Patcher sein können.

Ich hab dann für die Neuinstallation Windows 7 benutzt, vorher natürlich schön im BIOS auf AHCI umgestellt, um Trim auch nutzen zu können. Das funktionierte auch ein paar Tage problemlos, daher dachte ich, daß die Probleme wohl doch in einer irgendwie kaputten Windows-XP-Installation begründet waren.

Bei der Aktion habe ich übrigens die Platten ein paarmal umgesteckt (wegen Backup auf andere Platten usw.), so daß es auch nicht an einem lockeren SATA-Kabel liegen kann. Bin auch nicht drangekommen, also Wackelkontakt schließe ich aus.

Heute ist es aber wieder passiert, und ich hab das erste Mal gesehen, wie ScanDisk bei Win7 aussieht, die Freude hielt sich aber in Grenzen.

Hier noch ein Screen von Everest mit den Smart-Werten (kann ich nicht wirklich interpretieren, sieht aber meiner Meinung nach nicht gut aus):


Die andere, normale Platte im Rechner ist übrigens völlig unauffällig, funktioniert einwandfrei und hat auch optimale Smart-Werte.


Ich bräuchte dazu mal eine zweite Meinung (oder gern auch mehrere^^). Ist das ein klarer RMA-Fall? Kann ich noch irgendwelche Tests ausführen, um ganz sicher zu sein, daß es die SSD ist (z.B. irgendein Herstellertool)? Ich will ja nicht die SSD wochenlang in der Weltgeschichte rumschicken, um sie dann mit dem Vermerk "keine Reparatur ausgeführt, war ok" zurückzubekommen und meine Probleme sind noch da. Eine funktionierende WinXP-Installation auf einer anderen Platte wäre noch da für irgendwelche Tests.
 
Zuletzt bearbeitet:
Lad dir doch mal HDD_erase,oder besser Sanitary_erase und lass das drüber.

Das löscht die cluster sauber,du hast dann ne SSD im Werkszustand.Danach eine Schnellformatierung durchlaufen lassen und dann Win7 neu installieren,im Storage Controller natürlich vorher auf AHCI stellen.

Wenn DAS nichts hilft wird gar nichts mehr helfen.
 
überprüf mal die kabel! der ata crc error wert deutet auf ein defektes oder wackeliges kabel hin.

übrigens hat die firmware 1571 einen fehler, der zu erhöhter abnutzung der zellen führt! gerade bei mlc-chips ist es also nicht gerade von vorteil diese fw längere zeit zu benutzen.
 
Danke für die Antworten. Ich bin aktuell noch in der Beobachtungsphase, komischerweise ist bisher kein weiterer Fehler aufgetreten. Aber irgendwas ist damit. *seufz* Bei mechanischen Platten war das einfacher, wenn sie sich hörbar kaputtgeschnetzelt hat, war man wenigstens sicher, daß sie hin ist.
 
Hat wieder angefangen :(

SATA-Kabel ist inzwischen getauscht, aber kein Effekt, Smart-Werte sehen weiterhin genauso mies aus.

Ich glaub, ich werde die jetzt in die RMA geben.
 
Hast du schon das Secure Erase durchgeführt?
 
Nee, hab ich mir geschenkt, das Ding ist in der Post. Aber auch ohne Secure Erase sollte es ja wohl keine Fehler hageln und miese SMART-Werte abgeben.
 
Hättest Du nicht einschicken müssen, die SMART-Werte sind für eine Indilinx-SSD völlig normal. Du verursachst nur unnötige Kosten. Und für Dein Flash-Problem beim Firmwareupdate gibt es auch eine Lösung. Hast nur im falschen Forum gefragt... ;)

Gruß
 
Und die Datenfehler sind normal, oder wie?

Naja, ich warte jetzt erstmal ab, was sich tut.
 
Die Datenfehler "können" normal sein.Deswegen hatte ich dir ja ein Erase vorgeschlagen um sicher zu gehen bevor die Karte unnötig verschickst.
Du hast (wenn ich das richtig gelesen habe) kein auto-TRIM genutzt,was dazu führt dass die Daten in der Zelle bleiben,egal ob gesunde oder defekte Daten,egal ob noch gebraucht oder bereits "gelöscht".Es bleibt alles vorhanden.Alles was du gelöscht hast in der Laufzeit deiner SSD ist geblieben.Das kann durchaus zu Komplikationen,sowohl bei Scans,als auch beim BS selber führen.
Mit einem komplett Erase werden die Zellen gelöscht und in den Ursprungszustand versetzt.
Es kann sein dass bereits Zellen hops gegangen sind,es kann aber genauso sein dass dein Fall nur ein softwareseitiges Problem war.
Powermike muss ich da insofern Recht geben dass du auf SMART-Werte bei SSDs nicht allzuviel geben solltest.
 
Erstens hat er das Trim Tool ausgeführt, was die Fehler bereinigen sollte und anschließend traten ebenfalls wieder Fehler unter Win7 mit Trim auf! Lest ihr überhaupt den Eingangspost?

Ich denke er hat mehr als genug getan und ich möchte nicht wissen was ihm da an Arbeitszeit draufgegangen ist, wenn ihr schon von Kosten sprecht...
 
Wenn ich das nicht völlig falsch verstanden habe, dann können leere Zellen sofort beschrieben werden, während volle Zellen beim Schreibvorgang erst gelöscht werden müssen, bevor sie beschrieben werden können. Wenn ich also diesen ganzen Kram mit Trim, Erase (was ja auch kein Zaubermittel ist, sondern nur alle Zellen komplett auf einmal löscht, während Trim das nach Bedarf stückchenweise macht) usw. nicht mache, dann geht die Schreibperformance in den Keller, das ist mir klar. Aber davon, daß man dann jede Woche das OS neu installieren darf, weil es sich zerlegt, muß ich ja wohl nicht ausgehen.

Wenn es an vollen Zellen liegt, wieso tritt das erst jetzt auf, nachdem die Platte schon mit einem Vielfachen ihrer Kapazität beschrieben wurde, also alle Zellen sowieso voll waren? Und nach Benutzung des Trim-Tools hätte ich ja wieder einiges an Zeit gewinnen müssen, wenn das der Grund gewesen wäre, wesentlich mehr als nur zwei Tage (in denen die ca. 50GB, die getrimmt wurden, noch nicht wieder voll beschrieben worden sind, weil ich aus Sicherheitsgründen sowieso auf einer anderen Platte gearbeitet habe). Und wenn es an defekten da zu oft beschriebenen Zellen liegt, wieso traten die Dateifehler auch bei Systemdateien auf, die ich damals bei der Windows-Installation auf die neue SSD geschrieben hatte und die seitdem nicht mehr verändert wurden, d.h. wo die Zellen genau einmal beschrieben und nie gelöscht worden sind?

Also ich würde mal behaupten, die These "der User ist schuld" klingt zwar bequem (wenn auch wenig freundlich), aber ist den Fakten nach wohl nicht ganz haltbar.

Wie gesagt, die Diskussion ist jetzt erstmal sowieso akademisch, da ich die SSD nicht mehr hier habe. Ich warte jetzt ab was aus der RMA wird, wird wohl einige Wochen dauern. Wenn der Hersteller tatsächlich auch meinen sollte, daß ich selbst schuld bin (z.B. weil Powermike der Garantiefallabschmetterungsbeauftragte bei SuperTalent ist?), dann möchte ich aber die Begründung dafür sehen.
 
Es bleibt alles vorhanden. (...) Das kann durchaus zu Komplikationen,sowohl bei Scans,als auch beim BS selber führen.
Davon lässt sich NTFS nicht im geringsten beeindruckend und wäre übrigens bei einer konventionellen HDD nicht viel anders.
 
auch statische daten, wie z.b. systemdateien, werden durchs wear-leveling hin- und hergeschoben und können somit in defekten zellen landen.

ich denke, dass einfach diverse zellen hops gegangen sind, da sie aufgrund des bugs in der firmware 1571 übermäßig strapaziert wurden
 
auch statische daten, wie z.b. systemdateien, werden durchs wear-leveling hin- und hergeschoben und können somit in defekten zellen landen.
Das halte ich für unwahrscheinlich. Wear-Levelling möchte doch für eine gleichmäßige Nutzung sorgen. Wieso sollte es dann zusätzliche Schreibzugriffe erzeugen?

Gibt es dafür Belege? Allenfalls Garbage Collection kann beim Zusammenfassen von Blöcken solche zusätzlichen Schreib- und Löschzyklen erzeugen.
 
der zusätzlich löschvergang wird in kauf genommen um auch die bisher wenig gelöschten zellen mit den statischen daten "abnutzen" zu dürfen und somit also eine gleichmäßig abnutzung aller zellen zu erreichen.
angenommen eine ssd ist zur hälfte mit statischen daten gefüllt, die nur einmal geschrieben aber nie verändert wurden, und der rest der ssd enthält sich ständig verändernde daten, dann würde eine ssd, deren wear-leveling statische daten ncith bewegt, alle schreibzugriffe auf die hälfte ohne statische daten konzentrieren und deren zellen durch häufiges löschen abnutzen, während die andere hälfte noch nie gelöscht wurde. angenommen die ssd hat 10gb und die zellen gehen nach exakt 10000 löschvorgängen hops, dann geht diese ssd unter obigen vorraussetzungen nach 50tb übern jordan. wenn jetzt aber z.b. alle 100 löschvorgänge eine zelle mit statischen daten gefüllt wird um die zuvor geschonten zellen mit dynamischen daten zu belasten, dann hält die ssd fast 100tb aus. das umschaufeln der statischen daten würde dabei den "verbrauch" an löschvorgängen um 1% erhöhen, dabei aber die lebenszeit der ssd beinahe verdoppeln, da alle zellen etwa gleichoft gelöscht und damit abgenutzt wurden.

ich hoffe, das war einigermaßen verständlich.

einen link hab ich gerade, der besagt, dass intelligente ssd statische daten umlagern um das wear leveling zu verbessern:
http://www.anandtech.com/show/2829/6 im absatz unter der tabelle
 
Zurück
Oben Unten