Hardwarefehler? Sandisk Cruzer Extreme 64GB behalten oder tauschen?

[L1nus]

Ich habe mir heute den 64GB Cruzer Extreme (USB 3.0-Stick) geholt und bin soweit auch zufrieden.
Große Dateien kopiert er zügig und auch bei einem Ordner mit vielen Fotos war der Kopiervorgang schnell.
Habe den Stick auch mit H2testw getestet und es wurde kein Fehler festgestellt.
Der Stick konnte voll geschrieben und wieder richtig gelesen werden:

Achtung: Nur 61026 von 61035 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 151 MByte/s
Leserate: 157 MByte/s
H2testw v1.4


Aaaaber:
Wenn ich den Stick mit CrystalDiskMark teste, dann gehen die ersten 3 Tests gut, aber der letzte Test stürzt immer ab
Beim letzten Write-test, bricht der Test ab und das Licht des USB-Sticks geht aus... und das reproduzierbar (egal ob 500MB/2GB usw..)
Interessanterweise wird der Stick noch unter "Computer" angezeigt und ich kann sogar was drauf kopieren.
Soll ich den Stick lieber tauschen oder ist die CrystalDiskMark nicht für USB-Sticks geeignet?
LG
- L1nus

 

[Tritze1693]

Hi,

wenn der USB-Stick, wie du sagst, trotzdem funktioniert, wieso solltest du ihn dann austauschen?

Grüße

 

[yaegi]

hiermit kannste das ding mal auf fehler testen:
http://www.heise.de/download/h2testw.html

 

[L1nus]

Hi, also ich hab mir schonmal nen teuren Stick geholt, der nach paar Wochen kaputt gegangen ist und man hat mir hier damals gesagt, man solle die Sticks immer erst auf Herz und Nieren prüfen, bevor man sie dauerhaft verwendet. möchte halt nicht, dass mir das nochmal passiert...
Der letzte Stick hat auch soweit funktioniert und danach war er völlig im Eimer... möchte mich jetz halt nur absichern

Ergänzung (5. März 2015)

hiermit kannste das ding mal auf fehler testen:
http://www.heise.de/download/h2testw.html

Hast du meinen Beitrag gelesen? Habe dies doch gemacht oder meinste noch was anderes? O__o

 

[Hallo32]

Sandisk Support anschreiben.

 

[Holt]

Bei Test mit der QD32 dürfte eher Dein USB3 Treiber ein Problem haben, denn das normale USB Bulk Protokoll unterstützt kein NCQ und der muss diese gewaltige Warteschlange dahr selbst verwalten, für den Stick selbst ist das dagegen nicht anders als der Test darüber mit 4k und QD1, weil er eben immer nur einen Befehl bekommt, wenn der davor abgearbeitet ist. Von daher würde ich CDM auch den untersten Test abwählen, wenn nicht das UASP Protokoll genutzt wird, das kann NCQ.

Der Stick ist deswegen also wahrscheinlich nicht defekt und im Alltag werden auch keine 32 parellelen Zugriffe an ihn bzw. den Treiber gestellt werden, den zu tauschen ist nicht nötig, da ja h2testw auch fehlerfrei durchgelaufen ist.

 

[Hallo32]

@Holt

Es darf nicht crashen. Ob es der Treiber ist, sollte sich kontrollieren lassen. Sandisk dürfte in diesen Fall eine Liste mit "defekten" Treiber Versionen haben.

 

[L1nus]

kleiner nachtrag, habe den as ssd durchlaufen lassen:



warum steht da "16k bad"? Der stick ist fabrikneu, wieso stimmt das Alignment nicht? Kann/MUss ich das korrigieren?

 

[Holt]

Das mit den 16k bad ist so nicht korrekt, 16k it auch ein ganzes Vielfaches von 4k und damit stimmt das Alignment. AS-SSD zeigt da vermutlich bad an, weil der Wert unter den 31k liegt, bei denen XP die erste Partition angelegt hat. Ignoriere das bad einfach!

Aber wenn es bei AS-SSD mit 4k_64 ging, dann ist das Verhalten komisch und ich würde mal das RAM richtig testen, damit RAM Fehler auszuschließen sind. Dazu stellt man alles im BIOS so ein, wie es auch nachher läuft, also keine OC-Tweaktools unter Windows verwenden! Dann die iso / img von Memtest86+ von CD oder USB-Stick booten, denn man kann nicht unter Windows sinnvoll das RAM testen. Es sollten min. 6 PASS abgewartet werden und es darf dabei kein einziger Fehler auftreten, also am Besten über Nacht laufen lassen. RAM-Fehler können die unmöglichsten Probleme erzeugen.

 

[Hallo32]

Du hast den Stick mit Fat32 formatiert?

Falls ja, dann nimm Null als Offset oder ein vielfaches von 32k.

 

[Holt]

Aber Hallo32, seid wann hat die Formatierung der Partition Einfluss auf deren Offset? Das solltest Du nun schon besser wissen!

L1nus, lass Dich nicht verunsichern, die 16k Offset sind kein Problem und so gut wie jeder andere Offset der ein ganzes Vielfaches von 4k ist.

 

[Hallo32]

Schau dir mal das Changelog von AS SSD an. Der Ansatz dort ist richtig und logisch.

1.4.3704.27281
+Alignment Anzeige orientiert sich an der tatsächlichen Clustegröße

Wenn du jetzt die Cluster einer Page um einen Faktor verschiebst, der kein vielfaches des Clusters selbst ist, dann passen die Cluster nicht mehr bündig in einer Page.

Bsp.:
Nand Page 256k
Cluster Fat32 Stick >32GB -> 32k

256k/32k = 8 -> 8 Cluster passen in einer Page

Jetzt mit einen Offset von 16k
256k-16k = 240k
240k/32k = 7,5 -> es passen 7 ganze Cluster in einer Page und der letzte Cluster muss auf 2 Pages verteilt werden. Was bekannterweise ungünstig ist.
Dieses zieht sich auch über die Block Grenzen hinweg.

Bei NTFS sind die 4K Cluster bis 16TB Standard und daher fällt es dort noch nicht auf.

 

[Holt]

Die Cluster passen sowieso nicht bündig in eine Page, wenn die Größe der Cluster nicht der Größe der Page entspricht und da es noch keine NANDs mit einer Pagesize von 32 oder mehr kiB gibt, ist das egal. Außerdem sind die SSD Controller und so einen hat der Stick ja, auf 4k Schreibzugriffe optimiert und daher ist es ihnen auch egal, ob die NANDs nun 8k oder 16k Pagesize haben. Bei 16k Offset und 8k oder 16k Pagesize ist auch bei einer Clustergröße von 32k auf jeden Fall ein Cluster immer 4 bzw 2 Pages groß und auch korrekt alignt, selbst wenn der Controller auf Schreibzugriffe mit Pagesize optimiert wäre.

 

[Hallo32]

Spätestens auf Block Eben erwischt dich das Problem.

 

[Holt]

Auf Blockeeben ist das auch total egal, einmal weil die neueren SSD Controller gar nicht so etwas ein Block-Alignment haben, allenfalls die einfach USB-Stick Controller und frühe SSD Controller wie der JM602, aber selbst wenn spielt es doch keine Rolle wie viele Pages in dem Block der gerade als ersten gemappt wird am Anfang frei sind. Das wäre bei so primitiven Controler die nur auf Blockebene mappen können auch dann allenfalls ein Unterschied, wenn die Clustergröße der Größe eines Block entsprechen würde, also irgendwas von 512k, 1M oder gar 2MB, die Große ist ja auch i.d.R. garnicht bekannt.

Also vergiss es, es wird ja auch nicht oft auf den ersten Pages geschrieben, das Alignment ist nur wichtig, weil alle anderen Cluster sich entsprechend ausrichten und ob nun 16k oder 64k oder 1024k macht für über 99% der Schreibzugriffe überhaupt keinen Unterschied, da die sowieso eine weit höhere Adresse gehen, zumal bei einem Stick mit 64GB Kapazität.