SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 1|2]

Status
Für weitere Antworten geschlossen.
Mechkilla schrieb:
Falsch.

Die Platte verliert keine Daten sobald sie voll ist !

Sie braucht für extreme Schreiboperationen einfach zu lange, sobald alle Flashblöcke belegt sind. In diesem Fall hat das Wear-Leveling/Write-Combining einfach zuviel zu tun, um Platz für neue Daten zu schaffen. Derweil füllt sich dann der Cache (geht recht schnell) und die SSD gibt dann wohl einfach keine Rückmeldung an das OS zurück, weil sie ziemlich beschäftigt ist. Deshalb entfernt Windows die Platte und da dies nicht gesittet vor sich geht, verliert die SSD dann die Daten.
Wäre so, als wenn ihr einen USB-Stick oder eine Platte einfach abzieht, während noch Daten darauf geschrieben werden. Nicht umsonst soll man USB-Sticks erst abmelden, bevor man sieh vom Rechner trennt.

Vielleicht wurde der Fall beim Erstellen der Firmware nicht bedacht, denn normalerweise sollte eine Hardware dem System mitteilen können, wenn es nicht aufnahmebereit ist. Nennt sich Handshake. Tut sie das nicht, glaubt das OS, das angesprochene Gerät ist nicht da oder defekt.

Mechkilla
Zum Vergrößern anklicken....

Eigentlich clever gemacht...
Bei normalem Gebrauch wird die SSD ja nicht so extrem schnell beschrieben wie in Benches. Die interne Verwaltung hat also genug Zeit die belegten Zellen (unter Windows scheinbar frei) im Hintergrund in Ruhe zu löschen.

Was ich allerdings nicht verstehe, dass der Controller es nicht schafft eine quickformatierte UD allmählich wieder zu heilen.

Und tritt der Ausfall und der Perf.-Einbruch definitiv nur bei Füllung aller Zellen ein?


@ all

Vielleicht ist ja jmd so mutig und lässt einen Bench mit IOmeter (mit 100% random write) 30-60min. laufen.
Vorher und nacher einen Bench mit HDtune machen.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
kaguya schrieb:
Naja man muss ich ja nciht gleich von der Technik abwenden, die Vorteile sind trotzdem enorm. Einfach eine andere SSD wie die Corsair S128 oder Mtron nehmen, die haben solche Probs nicht. Ansonsten erst mal ein FW Update abwarten ;)
Zum Vergrößern anklicken....

Schön und gut aber ich habe kein bock für 64GB 300 € zu bezahlen...

Bei 200 € hört bei mir der spaß auf..
 
@Snoopy69
Es geht nicht um Benches, es reicht schon einen Ordner mit sehr vielen kleinen Dateien auf eine ehemals volle Partition zu kopieren um die Probleme zu verursachen.
Im Prinzip kickt Windows die Platte einfach nur zu schnell weil es keine Rückmeldung bekommt, das sollte man eigentlich relativ leicht lösen können denke ich.
 
Snoopy69 schrieb:
Und tritt der Ausfall und der Perf.-Einbruch definitiv nur bei Füllung aller Zellen ein?
Zum Vergrößern anklicken....

Während ich die Platte das erste mal gefüllt hatte, blieben die sequenziellen Schreibraten im grünen Bereich (laut h2testw_1.4 bewegten sie sich um 140-150mb/s)....Nachdem ich darauf hin den Q-Format durchgeführt hatte, nutzte ich FC-Test.
Wo anfänglich 3sec für ein Pattern reichten, brauchte er nun ~9sec...andere Patterns welche ~20sec benötigten brauchten 40-50sec..
Ahja, bevor das Laufwerk verschwand sank die Schreibleistung fast exponentiell. Mit jedem neuen Pattern wurde die SSD um Welten langsamer!


Man sieht also, dass die bereit beschriebenen Zellen für den Controller ein großes Hindernis darstellen.
 
Zuletzt bearbeitet:
Ich wollte mir ein UD 64GB als Systemplatte gönnen, ist davon nun abzuraten ?

Grüße
Sascha
 
@ kaguya

Hab ja nicht geschrieben, dass es nur um Benches geht, sondern um das zu schnelle Füllen der Zellen.
Der Controller beschreibt bereits gelöschte Zellen und löscht nebenbei noch physikalisch gefüllte Zellen, die unter Windows schon als freier Platz erscheinen.
Das Beschreiben geht also wesentlich schneller als im Hintergrund gelöscht werden kann.
Bei normalem Gebrauch sollte eig. nichts passieren.

Benches also möglichst nur lesend ausführen bzw. writes nicht zuviele.

Aber ich hatte weiter oben schon in gewisserweise Recht.
Das gleiche Problem hat Intel auch bei zuvielen Benches und noch immer nicht im Griff! ;)



@ acczzz

Sollte man MLCs nicht generell VOR einem Bench komplett formatieren? ;)
Werksfrische MLCs sollten schneller als einmal komplett formatierte sein.
Bei SLC gibts keinen Unterschied.
 
Zuletzt bearbeitet:
ich würde sagen man sollte aufjedenfall noch ein bisschen warten ob sich da was tut in Richtung Firmware. Wenn man tägliche Backups macht und sehr sensible Daten nicht auf der SSD speichert kann man sie auch jetzt schon verwenden.

---------- Beitrag hinzugefügt um 14:29 ---------- Vorheriger Beitrag war um 14:27 ----------
Snoopy69 schrieb:
Bei normalem Gebrauch sollte eig. nichts passieren.
Zum Vergrößern anklicken....

Das sehe ich nicht so. Wenn alle Blöcke auf der SSD bereits mal beschrieben wurden (dazu muss die SSD nicht voll sein, es müssen nur ab und zu Daten gelöscht worden sein zb, was früher oder später eh passiert) und man dann zb ein großes Softwarepaket installiert könnte ich mir gut vorstellen das genau dieser Fehler auftritt.
 
Ich lese den Thread ja nun schon die ganze Zeit mit, aber jetzt wollte ich mich doch mal bedanken bei Euch! Hatte mir nämlich bereits eine UD ME bestellt, allerdings konnte ich die heute noch stornieren, das erspart mir wohl eine Menge Ärger.

Eigentlich wollte ich meine Raptor mal durch was schnelleres ersetzen, aber funktionieren sollte die SSD dann schon... Naja, ich warte dann erstmal eine neue Firmware ab, die vielleicht hilft, ansonsten gibt es ja noch die Summit, wenn die bezahlbar ist, wäre die ggf. auch eine Option.
 
Snoopy69 schrieb:
Eigentlich clever gemacht...
Bei normalem Gebrauch wird die SSD ja nicht so extrem schnell beschrieben wie in Benches. Die interne Verwaltung hat also genug Zeit die belegten Zellen (unter Windows scheinbar frei) im Hintergrund in Ruhe zu löschen.

Was ich allerdings nicht verstehe, dass der Controller es nicht schafft eine quickformatierte UD allmählich wieder zu heilen.

Und tritt der Ausfall und der Perf.-Einbruch definitiv nur bei Füllung aller Zellen ein?
Zum Vergrößern anklicken....

Wie soll die SSD das machen? Sie weiß ja nicht, das die Partition (schnell-)formatiert worden ist. Für die SSD ist es so, als ob ein paar Bytes geschrieben wurde, da ja das OS bei einem Quickformat nur die Dateiverweise überschreibt (und damit löscht). Selbst ein Vollformat ist für die SSD nur ne Menge geschriebener Daten. Daher kann die SSD gar nicht wissen welche Sektoren/Cluster/Flashblöcke frei geworden sind, so dass sie sie vorsorglich in aller Ruhe löschen kann.
Erst wenn schon genutzte Flashblöcke überschrieben werden sollen, weiß die SSD, "aha, diese Bereiche darf ich löschen".

Ich glaub das haben immer noch einige nicht verstanden, das wir hier 2 Ebenen haben, über die geredet werden muss (einerseits das Dateisystem und andererseits die Verwaltung der Flashblöcke), die beide keine gegenseitige Verbindung haben.

HDDErase nutzt interne Kommandos aus der ATA-Spezifikation und sagt der SSD, "lösch mir mal folgende Bereiche ...". Das tut die dann und diese Bereiche sind dann leer, bis sie wieder mit Daten gefüllt werden. Dann geht das Problem wieder von vorne los.

Solange die SSD noch echt leere Bereiche hat, kann sie durch Umorganisation diese für neue Daten nutzen und braucht anderen nicht zu löschen bzw. markiert diese als nicht mehr genutzt und löscht sie dann bei Gelegenheit. Wegen der Ermüdung der Flashzellen bei jedem Löschvorgang, versucht das Wear-Leveling dieses Löschvorgänge so gering wie möglich zu halten.

Und ja, der Ausfall und Performanceeinbruch tritt erst nach Füllung auf, hab das schön beobachten und nachvollziehen können. Meine eigentliche Intention mit dem übermässigen fc-test war herrauszufinden, wie stark sie bei Füllung einbricht (da ja dauernd vom 80%-Cap-Bug der Intel geredet wird). Das ich sie damit überforder, sobald sie die 100% erreicht bzw. überschritten hat, hät ich nicht gedacht.

Mechkilla
 
FB07 schrieb:
Schön und gut aber ich habe kein bock für 64GB 300 € zu bezahlen...

Bei 200 € hört bei mir der spaß auf..
Zum Vergrößern anklicken....

wie man hier sieht, hört aber darunter der Spaß auf


Es gibt User hier im Forum, die seit Monaten davon abraten eine MLC als SysPlatte zu verwenden, hat aber niemanden interessiert
 
Zuletzt bearbeitet:
USAR schrieb:
Es gibt User hier im Forum, die seit Monaten davon abraten eine MLC als SysPlatte zu verwenden, hat aber niemanden interessiert
Zum Vergrößern anklicken....
Neue Generation - neues Glück! Manchmal ändert sich halt auch etwas :d

@Snoopy
Ich kann gar nicht mehr zählen, wie oft ich die Platte schon formatiert habe :hmm:...kann aber sein, dass ich sie nach dem HDDErase nicht wieder formatiert habe :xmas:
 
acczzz schrieb:
Der 9'te Durchlauf hat es nun gebracht. Im Folgenden ein paar Einträge im Syslog:

12:25:13 - Bei einem Auslagerungsvorgang wurde ein Fehler festgestellt. Betroffen ist Gerät \Device\Harddisk3\DR3.
12:25:16 - Anwendungspopup: Windows - Fehler beim verzögerten Schreibvorgang: Exception Processing Message 0xc000a082 Parameters 0x000007FEFDE27240 0x000007FEFDE27240 0x000007FEFDE27240 0x000007FEFDE27240
12:25:16 - Das Gerät "SATA FTM28GX25H SCSI Disk Device" (SCSI\Disk&Ven_SATA&Prod_FTM28GX25H&Rev_1215\5&deff19b&0&000100) wurde ohne vorbereitende Maßnahmen vom System entfernt.
12:25:16 - Das Gerät \Device\Harddisk3\DR3 ist für den Zugriff noch nicht bereit.
........
12:25:16 - {Datenverlust beim Schreiben} Nicht alle Daten für Datei "S:\Durchlauf9\1551.5422" konnten gespeichert werden. Die Daten gingen verloren. Dieser Fehler kann ausgelöst werden, wenn das Gerät entfernt wurde oder das Medium schreibgeschützt ist.



SSD weg - User unglücklich! :wall::wall::wall:


Edit: Im Eventlog meines Highpoint steht --> 2009/3/18 12:25:16 Disk failed.
Zum Vergrößern anklicken....



Wäre vielleicht einen Versuch wert:
unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk] den Wert "TimeOutValue" auf z.B. "60" (dezimal, alternativ auch bis zu 120sec) zu setzen (oder neu zu erstellen, afaik ist der Wert nur bei Win Server OS per default da). Die Lösung hört man zwar überwiegend in Zusammenhang mit VMs oder Server-Problemen, aber es ist ja auch kein großer Aufwand, das zu probieren. Ich würds ja selber testen, aber dank gesperrter EC-Karte vergammelt meine UD in der Packstation :argh:

http://communities.vmware.com/message/662018 schrieb:
The Delayed Write failed error happens when Windows does not complete an i/o within the "acceptable" time period.

You can set a timeout value with a reg key;

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk]
"TimeOutValue"=dword:0000003c

In this example x'3c' is 60 seconds. This will force Windows to allow 60 seconds for the i/o to complete before issuing the delayed write failure....
Zum Vergrößern anklicken....

Mehr zum Lesen:
http://www.osronline.com/showThread.cfm?link=3557
http://publib.boulder.ibm.com/infoc...rage.ssic.help.doc/f2c_w2ktimeout_198ovw.html
 
Zuletzt bearbeitet:
Welche SSD: UltraDrive ME
Größe: 64 GB
Firmware-Version: 1215
Alignment: nein
An welchen Controller: AMD SB700
Betriebssystem: Vista Ultimate 64bit mit SP2 RC1
Rückschreibcache: Ja

kurze Beschreibung als der erste Fehler aufgetreten ist:
SSD mit mit diversen Aktionen (mehrfach) befüllt, dann Quickformat, anschliessend eine Testreihe FC-Test auf leerem Laufwerk => Bei beliebigem Copytest verschwindet das Gerät komplett aus dem System. Kaltstart nötig um die UD wieder ins System zu bringen. Partiton im Gerätemanger und Explorer nur noch als "RAW" gekennzeichnet, nach einfachem Quickformat wieder nutzbar.

Fehler ist reproduzierbar!


Ah, danke Unu, genau das vermute ich ja. Ich werd mal den Wert höher setzen und schauen was passiert.
 
Zuletzt bearbeitet:
USAR schrieb:
wie man hier sieht, hört aber darunter der Spaß auf


Es gibt User hier im Forum, die seit Monaten davon abraten eine MLC als SysPlatte zu verwenden, hat aber niemanden interessiert
Zum Vergrößern anklicken....

Ist klar aber wer kauft sich schon so eine teure Datenplatte für sein Home-PC?
 
Mechkilla schrieb:
Wie soll die SSD das machen? Sie weiß ja nicht, das die Partition (schnell-)formatiert worden ist. Für die SSD ist es so, als ob ein paar Bytes geschrieben wurde, da ja das OS bei einem Quickformat nur die Dateiverweise überschreibt (und damit löscht). Selbst ein Vollformat ist für die SSD nur ne Menge geschriebener Daten. Daher kann die SSD gar nicht wissen welche Sektoren/Cluster/Flashblöcke frei geworden sind, so dass sie sie vorsorglich in aller Ruhe löschen kann.
Erst wenn schon genutzte Flashblöcke überschrieben werden sollen, weiß die SSD, "aha, diese Bereiche darf ich löschen".
Zum Vergrößern anklicken....

Ich weiss schon wie das funktioniert ;)
Bei normalem Gebrauch dürfte aber nichts passieren.
Wird eine 1GB grosse Datei gelöscht, müsste der Controller bei idle bzw. mit ganz weniger Last die Zellen von 1GB im Hintergrund komplett leeren.
Wie schnell das geschieht und wann kannst du vielleicht beantworten.
Es müsste jedenfalls nach einer gewissen Zeit 1GB geleerte Zellen zur Verfügung stehen.

Bei Benches bzw. bei zu schneller Befüllen aller Zellen kommt es halt zum Crash!
 
Zuletzt bearbeitet:
Also ich habe das jetzt noch 4-5 mal durchgetestet, dabei habe ich nach dem Befüllen & Quickformat folgende Tools probiert:

- Eraser (erase unused space mit 0 Bytes überschrieben)
- Diskeeper Hyperfast (tut bei einem leeren Drive eh nichts, da auf Dateiebene)
- Raxco Perfect Disk 10 (Consolidate Freespace, tut bei leerem Drive ebenfalls nichts bzw ist sofort fertig)

Danach FC-Test und jedesmal wieder der selbe Fehler => SSD verschwindet komplett aus dem System.
Mit normalen kopieren von großen Ordnern oder h2testw konnte ich den Fehler allerdings noch nicht hevorrufen, bisher nur mit FC-Test.
 
Eins fällt bei allen Fehlerberichten auf: OS ist irgendeine Version von Windows :d
 
Snoopy69 schrieb:
Wird eine 1GB grosse Datei gelöscht, müsste der Controller bei idle bzw. mit ganz weniger Last die Zellen von 1GB im Hintergrund komplett leeren.
Zum Vergrößern anklicken....

Genau das geht aber nicht, weil die SSD nicht weiss wenn eine Datei gelöscht wurde, sie löscht nur dann wenn das Dateisystem einen bereits beschriebenen Block wieder beschrieben will, die SSD kennt den Zustand des Dateisystems aber nicht. Daher dann auch die Probleme wenn die SSD einmal voll war und nicht per HDD Erase erased wurde.
 
Zuletzt bearbeitet:
rolf :banana::banana::banana::bigok::bigok:

Nicht aufregen warn Spass!

Und ---Mist zu schnell auf senden gedrückt-- das mit dem Timeout werde ich auch testen! Mal sehen was das bringt.

Bei mir war ja wie gesagt der Ordner defekt, die SSD an sich in Ordnung.
 
Zuletzt bearbeitet:
@fdiskc2000: das liegt daran dass es für linux keine entsprechenden benchmark-tools gibt.

p.S.: wo bleibt ST defrag tool(der anscheinend zellen mit dateisystem abgleicht)
 
kaguya schrieb:
Also ich habe das jetzt noch 4-5 mal durchgetestet, dabei habe ich nach dem Befüllen & Quickformat folgende Tools probiert:

- Eraser (erase unused space mit 0 Bytes überschrieben)
- Diskeeper Hyperfast (tut bei einem leeren Drive eh nichts, da auf Dateiebene)
- Raxco Perfect Disk 10 (Consolidate Freespace, tut bei leerem Drive ebenfalls nichts bzw ist sofort fertig)

Danach FC-Test und jedesmal wieder der selbe Fehler => SSD verschwindet komplett aus dem System.
Mit normalen kopieren von großen Ordnern oder h2testw konnte ich den Fehler allerdings noch nicht hevorrufen, bisher nur mit FC-Test.
Zum Vergrößern anklicken....

Die Tools bringen eh nichts, einzig HDDErase (oder andere Programme die das ATA-Kommando an das SSD schicken) wird da irgendwas resetten können.

Versuche doch bitte den Registry-Tweak der weiter vorne gepostet wurde, das könnte temporär erstmal Abhilfe schaffen.


Und klar ist das OS immer Windows - wer Geld für SSDs ausgibt den stören meist die paar Euro für ne Windows-Lizenz auch nicht so.





Edit:
Snoopy69 schrieb:
Wird eine 1GB grosse Datei gelöscht, müsste der Controller bei idle bzw. mit ganz weniger Last die Zellen von 1GB im Hintergrund komplett leeren.
Wie schnell das geschieht und wann kannst du vielleicht beantworten.
Es müsste jedenfalls nach einer gewissen Zeit 1GB geleerte Zellen zur Verfügung stehen.
Zum Vergrößern anklicken....
Das geht erst mit TRIM - also Linux/Windows 7
 
Zuletzt bearbeitet:
Tekkno_Frank schrieb:
@webwilli

Ist ja prinzipiell auch die gleiche SSD!
Zum Vergrößern anklicken....

Richtig. Nur ist meine irgendwie noch toter als seine :d

Snoopy69 schrieb:
Ich weiss schon wie das funktioniert ;)
Bei normalem Gebrauch dürfte aber nichts passieren.
Wird eine 1GB grosse Datei gelöscht, müsste der Controller bei idle bzw. mit ganz weniger Last die Zellen von 1GB im Hintergrund komplett leeren.
Wie schnell das geschieht und wann kannst du vielleicht beantworten.
Es müsste jedenfalls nach einer gewissen Zeit 1GB geleerte Zellen zur Verfügung stehen.

Bei Benches bzw. bei zu schneller Befüllen aller Zellen kommt es halt zum Crash!
Zum Vergrößern anklicken....

Ja, irgendwie ist benchen definitiv schädlich für diese Art SSD. Und einige Benchmarks sind extrem böse.

Bei meiner(n) nächsten SSD(s) (ja, so schnell gebe ich nicht auf), werde ich erstmal die Finger von einigen Benchmarks lassen und das Ding nutzen, so wie es sich gehört.
 
kaguya schrieb:
Genau das geht aber nicht, weil die SSD nicht weiss wenn eine Datei gelöscht wurde, sie löscht nur dann wenn das Dateisystem einen bereits beschriebenen Block wieder beschrieben will, die SSD kennt den Zustand des Dateisystems aber nicht. Daher dann auch die Probleme wenn die SSD einmal voll war und nicht per HDD Erase erased wurde.
Zum Vergrößern anklicken....

Dann sollte ich meine Idee schnell patentieren lassen :d


Sukrim schrieb:
Edit:

Das geht erst mit TRIM - also Linux/Windows 7
Zum Vergrößern anklicken....
Gibts da keinen Tweak für XP und Vista?


webwilli schrieb:
Ja, irgendwie ist benchen definitiv schädlich für diese Art SSD. Und einige Benchmarks sind extrem böse.

Bei meiner(n) nächsten SSD(s) (ja, so schnell gebe ich nicht auf), werde ich erstmal die Finger von einigen Benchmarks lassen und das Ding nutzen, so wie es sich gehört.
Zum Vergrößern anklicken....

Dann wirde es früher oder später auch bei normalem Betrieb passieren - so ganz ohne TRIM.

KA, was sich Supertalent und OCZ dabei gedacht hat. Ich hätte sowas unabhängig vom OS integriert.
 
Zuletzt bearbeitet:
Sukrim schrieb:
Und klar ist das OS immer Windows - wer Geld für SSDs ausgibt den stören meist die paar Euro für ne Windows-Lizenz auch nicht so.
Zum Vergrößern anklicken....

Ah ja, also sind alle anderen OS kostenlos und frei? Also der Kostenfaktor hat damit mal null zu tun denke ich.

das liegt daran dass es für linux keine entsprechenden benchmark-tools gibt.
Zum Vergrößern anklicken....
Ok das lasse ich gelten, aber unter Linux, OS X etc. sollten doch dann die Platten auch "aussteigen" oder? Will damit sagen/fragen: ist das ein Problem des Betriebssystem oder nicht? Weil bisher eben nur Windows-User das hier gepostet haben. Und ich kenne nur 1 OS X User mit 2 x 64GB ST UD, der hat aber eben das Problem bisher nicht (im regulären Betrieb).
 
webwilli schrieb:
Richtig. Nur ist meine irgendwie noch toter als seine :d
Zum Vergrößern anklicken....

Kannst Du mal bitte aufhören, ich mach mir gleich in die Hosen :bigok::bigok:

Ist ja fast so wie bei Quimonda, die sind pleiterer als andere......

Hat jetzt jemand schon den Tweak mit dem Reg Key gemacht. Ich sitzt hier und kann nicht weg.
 
Bin auch noch auf der Arbeit :d

Ich könnte aber mal ne Linux Livecd reinschmeissen und die platte mal mit dd füllen.

Random Werte (dauert dann aba lange :() oder mit Nullen? Wie stress ich die Platte denn dann wohl unter Linux so richtig, sodass sie aussteigen könnte? N paar mal bonnie+ anwerfen udn gleichzeitig dd + hdparm oder so? :d
 
ich teste das ganze jetzt mal mit dem RegistryTweak, war bei mir allerdings schon auf 60 eingestellt (Vista Ultimate 64b), teste jetzt mal mit 240.
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

R
[User-Review] Lesertest zur Synology DiskStation DS224+
Antworten
0
Aufrufe
6K
_roman_
R
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh