Dritter SSD Ausfall in 2 Monaten

[Kowa]

Ich kann mir nicht vorstellen, dass die wegen dem Controller "kaputt" gehen. Hat mal jemand versucht die SSD gesundzubacken? Vlt ist es ja ein Problem im Herstllungsprozess.

 

[enzor]

Hey das ist ne coole Idee - werd ich machen, wenns meine mal erwischt.

 

[Lars_SHG]

Ja, das ist so eine Sache mit den SSDs, leider habe ich auch keine wirklich guten Erfahrungen, was Haltbarkeit betrifft, machen können! Jedenfalls im Vergleich zu HDs!

2x ist meine Intel 320 verstorben (nicht der Bug, Controller-Tod) --> Controler Intel
1x eine Muskin Calisto Deluxe --> mit SF-1200 Controller
1x eine Crucial C300 --> mit Marvell-Controller
Hingegen meine alte OCZ Agility2 E rennt wie am ersten Tag und ist auch noch nie ausgefallen......
Ich würde also zumindest bei mir kein pauschales Urteil über eine bestimmte Type aussprechen!

Ich habe jetzt immer eine weitere SSD, die alle 3 Tage eine exakte Kopie meiner Daten und des Betriebssystems macht. Das sichern der 100 GB dauert exakt 15 min. inklusive des wechselns der SSD im Backplane von außen.
Garantie hat man ja lange genug - man muß nur genug Ersatz SSDs haben.......

Dein Gedanke auf eine HD zu wechseln würde mir selbst dann nicht kommen, wenn alle SSDs gleichzeitig ausfallen würden, nie wieder HD als Systemlaufwerk!

 

[SavageSkull]

Mir ist nur diese Statistik bekantn und die Daten sind bezogen auf products sold between October 1st 2010 and April 1st 2011 for returns made before October 2011. Auf der letzten Seite gibt es noch einmal etwas aktuellere Zahlen.

Diese Statistik war einer der Hauptgründe warum ich zur Intel gegriffen habe.
Gerade dass die OCZ (damals war die Vertex 2 sehr beliebt) SSDs recht häufig ausfallen, darüber bin ich sogar ohne danach zu suchen gestoßen. In jedem bekannten Forum waren Threads darüber, wo sich über OCZ beschwert wurde.
Nachdem ich mich dann vor meinem SSD Kauf informiert hatte, fiel auch auf, dass die OCZ SSDs zum großen Teil günstiger als alle Konkurrenten sind.
Ebenso scheint es wirklich nicht drin zu sein, dass die SSDs in einer normalen Nutzungsdauer mal totgeschrieben sind. Ich denke nicht, dass ich die SSD länger als 6 Jahre in meinem Hauptrechner benutzen werde, einfach weil sie bis dato zu klein sein wird. Wenn sie dann noch läuft, kann sie gerne in ein Zweitsystem wandern, wo der Verlust dann auch nicht wirklich schmerzhaft ist.
Genauso scheint es nach den Tests, dass die Sandforce Controller auch nicht der perfekte Renner sind, da sie anscheinend durch Komprimierungen und anderen Korrekturen auf ihre tollen Werte kommen. In der Praxis scheint es kaum einen Unterschied zwischen den SSDs bezüglich ihrer Geschwindigkeit zu geben. Eine SSD ist erheblich schneller als jede HDD, aber auch eine alte Intel von vor 3 Jahren ist nicht spürbar langsamer als eine neue Crucial mit Sata3 6GB.

 

[Holt]

Ich kann mir nicht vorstellen, dass die wegen dem Controller "kaputt" gehen. Hat mal jemand versucht die SSD gesundzubacken? Vlt ist es ja ein Problem im Herstllungsprozess.

Das glaube ich nicht, die Chips wird Sandforce bei einem der Auftragsfertiger herstellen lassen, eigene Fabs haben die ja nicht. Die meisten SF-SSDs die ausfallen dürfte auch garnicht wirklich kaputt sein, die sind nur im Panik Lock. Der Sandforce hat wenig Rechenleistung und verschiebt die Aufgaben wie das Aufräumen des Flashspeichers auf später, weshalb die Schreib-Performance ja auch abfällt, wenn man mehr am Stück (innerhalb einer bestimmen Zeit) schreibt, als er an Speicher vorher freigemacht hat (Recovery State). Dann muß er das in Realtime machen und räumt aber trotzdem hinterher eben wieder auf, denn es sind ja nun alle Daten ungültig geworden, die an Adressen standen, welche überschrieben wurden. Solche Adressen werden ja nicht getimmt, TRIM gibt ja nur LBAs von gelöschten Dateien bekannt aber nicht die von überschriebenen (wozu auch).

Diese Aktivität in Idle ist wohl eines der Gefahrenpotentiale, denn wenn dabei der Rechner ausgemacht wird oder die SSD zum Stromsparen abschaltet, dann kann es wohl offenbar passieren, dass die internen Verwaltungsdaten inkonsitent sind, so wie es auch mit einem Filesystem passieren kann, wenn man den Rechner einfach so abschaltet.

Das scheint auch die Ursache beim 8MB Bug von Intel zu sein, nur dass dort das Problem bei Stromausfall während des Schreibvorgangs auftritt, die Verwaltungsdaten also nur während eines Schreibvorgangs kurz inkonsistent sind und nicht wiederhergestellt werden können.

Die meisten Filesysteme sind heute Journaling Filesysteme (auch NTFS) und leiden nicht mehr unter dem Problem, was aber wohl intern, für die Verwaltungsdaten bei der Intel nicht so implementiert ist. Gute SSD Controller haben ja ein Schattenfilesystem und merken sich ebene nicht nur, in welcher Flashadresse die Daten eines LBAs nun liegen sondern auch, welche LBAs zusammenhängend geschrieben wurden und damit so über die Flashkanäle zu verteilen sind, dass sie auch parallel und damit schnell wieder ausgelesen werden können.

Eine andere Ursache für die häufigen Ausfälle des SF könnte auch ein schlechtes Bad-Block Managment sein, wenn der Controller irgendwelche Daten fest auf einer bestimmten Adresse erwartet und genau dieser Flashblock kaputt geht, dann nutzt es natürlich auch nichts mehr, wenn alle anderen Flashblöcke noch heil sind.

Die genaue Ursache kennt aber nur Sandfocre und inzwischen vielleicht Intel, die ja in letzter Zeit auch viel an ihren SATA Treibern gearbeitet haben, was ehr für die erste These spricht.

 

[Kartonschachtel]

Interessante Details.



Habe mir jetzt eine Crucial M4 gekauft als Ersatz für meine noch funktionierende Corsair Force. Und für die defekte X32 von heute morgen habe ich mir eine normale WD Caviar gekauft.