News WD Blue 3D NAND: Vereinzelt Leistungsverlust beim Lesen alter Dateien

[Fabian_otto]

Das Problem ist seit der Samsung 8XX Serie bekannt. Da hilft nur DiskFresh und einmal im Jahr alles neu schreiben.

 

[Denniss]

oder ein intelligente bzw korrekt funktionierende Firmware der SSD

 

[Oely]

Kann mal jemand "Alte Dateien" definieren.

 

[Stormfirebird]

Bei mir konkret Dateien die vor etwas weniger als einem Jahr auf die SSD geschrieben wurden teils sehr starke Einbrüche. Der Zeitraum ist jetzt nicht festgenagelt, auch davor kann das durchaus schon auffallen.

 

[Bigeagle]

Wenn die SSD nicht nahezu voll ist, schreibt man damit viel zu viele Daten. Eine sinnvolles Backup-Software würde nur die belegten Sektoren sichern und nach dem TRIM der gesamten SSD wieder zurück spielen.

Die variante mit DD wäre zumindest einfach und erfasst alle Daten. Da muss man sich keinen Kopf machen ob auch die $bitmap und andere ntfs dateien neu geschrieben wurden. Meist dürfte da einfach ein Dateisystemtreiber Dateien sichern und zurückschreiben. Aber gerade die internen Daten des Dateisystems sind doch potentiell alt und noch an der gleichen stelle wie bei deren Erstellung.

Nur müsste man dazu wissen, welche Dateien betroffen sind und nicht nur, wie die durchschnittliche Leserate der gesamten Datei ist.

Der SSDReadSpeedTester speichert doch auch eine tsv Datei samt Pfad für die getesteten Dateien. Da muss man immer noch knobeln und ggf. je nach Dateigröße andere Schwellwerte nehmen, aber prinzipiell ist die Info für die getesteten Dateien da.
Ich frage mich aber ob es angesichts der ebenfalls vorhandenen Dateisysteminternen Daten überhaupt sinnvoll ist sich auf einzelne Dateien die man aus dem System selbst heraus testet zu beschränken. Bekommt man unter Windows überhaupt lesezugriff auf alles? Geschweige denn dass man die Dateien komplett neu schreiben kann. Ich weiß dass contig.exe auch interne NTFS Dateien defragmentieren kann, aber sonst? Nicht über den Explorer

Das klappt außerdem nur mit Dateien, die niemand geöffnet hat (z.B. Systemdateien, Datenbanken, VC-Container, Logfiles).

Das kommt noch dazu.

Wie sollte ein Programm erkennen ob ein Lesevorgang zu langsam ist?
So als gedanke müsste man ja:
1. mittlere (oder maximale?) Leserate ähnlich großer Dateien ermitteln (also bins mit 4k, 8k, 16k ... 1M, bis keine steigerung mehr eintritt)
2. alles was unter richtwert*faktor liegt mehrmals unter umgehung eines cachings noch mal lesen
3. alles was nicht besser wird als betroffen flaggen und z.b. in eine liste schreiben.

Potentiell könnte man noch automatisch alle ungewöhnlich langsamen dateien defragmentieren lassen bevor man sie erneut testet. Ausgehend von Windows+NTFS.

Wäre es da nicht sinnvoller den Datenträger offline zu testen, Schrittweise auszulesen und dabei die Geschwindigkeit zu messen? Da könnte man z.b. in 1 MB Blöcken lesen und einfach betroffene Blöcke neu schreiben. Leichter zu messen als kleinere Dateien und aus meiner Sicht sogar leichter aufzufrischen. Kein herumgefummel mit kleinen Dateien, keine Probleme beim Messen der Geschwindigkeit und keinen Ärger mit Rechten oder Sichtbarkeit der Dateien.
Nachteil ist nur dass das Programm keinen Fehler beim zurückschreiben haben darf und versehentlich Ursprungssektor+1 ansteuert und man eben den Datenträger offline testen muss.
Wenn da nicht jemand ein Tool dafür schreibt bleibt der einfache, faule Weg alles per DD zu sichern und zurückzuschreiben. :/

 

[MountWalker]

[...] Kamera-Speicherkarten mit dem FAT32-Dateisystem unterscheiden nicht nach Sommer- und Winterzeit. Änderungszeit ist die jeweils in der Kamera aktuell eingestellte Zeit. Abhängig davon, wann (Sommer oder Winter) man die Daten dann unter Windows auf den NTFS-Datenträger kopiert hat, zeigt Windows automatisch einen Offset von einer Stunde an. [...]

Hier muss ich mal eingrätschen: NTFS verwendet prinzipiell UTC-Zeitsptempel. UTC ist immer gleich, das gibt es keine lokalen Abweichungen und keine Sommerzeit. Windows zeigt dir im Explorer das ganze umgerechnet in deine jeweilige Lokalzeit an, aber der Zeitstempel selbst ist UTC. Und ja, auch wenn Windows die Hardware-Uhr im BIOS/UEFI auf Lokalzeit einstellt, werden die Zeitstempel, die in NTFS wirklich verwendet werden, von dieser (bescheuert) eingestellten Hardware-Uhr über deine Lokalisationsangaben im System in UTC umgerechnet und dann für die Anzeige in deinem Kontextmenü wieder von UTC auf Lokalzeit gerechnet. Der Zeitstempel in NTFS selbst ist in UTC, damit der Hedgefondmanager, der mit seinem Dienst-Schlepptopp 2002 (.com-Crash) zwischen New York und London pendelte, weil die Kinder noch in New York zur Schule gingen, beim Flug über den Atlantik die Zeitzone seines Schleppies ändern konnte, ohne die Zeitstempel im Dateisystem zu vermurksen.

 

[Gargamehl]

Sicher, dass die SLC Speicher hat?

Sorry, hast recht, hatte es falsch in Erinnerung - anscheinend MLC nicht SLC. (bin beim Alter von ~ 11 Jahren von fälschlicherweise von SLC ausgegangen)

 

[Marcus . R]

Da ich meiner Betroffenen Blue 3D nur noch bedingt traue, habe ich beschlossen, dass ich meine für die Wissenschaft opfere.

Nachdem sie frisch Formatiert war, habe ich ein paar Tage später wieder meinen Steam Ordner rüberkopiert und dann gerade eine "Eingangsmessung" durchgeführt.

Ich bin mir noch nicht sicher, in welchen Abständen ich prüfen sollte. Wöchentlich, oder reicht wohl auch ein mal im Monat?

 

[MichaG]

Ich frage mich immer noch, was der Graph da eigentlich anzeigt, wenn man mit den Werten links in der Tabelle vergleicht. Der Average Speed scheint jedenfalls jetzt ok zu sein.

 

[Stormfirebird]

Blau ist die Varianz für die Woche und rot der Durchschnittswert.
Man kommt nicht weiter wenn man da jetzt zu viel reininterpretiert.
Wichtiger ist es eig. im Log zu suchen und woanders Vergleichen zu können. Eine isolierte Messung hilft einem nicht weiter.

 

[Corpus Delicti]

Ich bin mir noch nicht sicher, in welchen Abständen ich prüfen sollte. Wöchentlich, oder reicht wohl auch ein mal im Monat?

Nur bei Langeweile.

Jährlich, um ganz sicher zu sein halbjährlich sollte ausreichend sein.

 

[b|ank0r]

oder ein intelligente bzw korrekt funktionierende Firmware der SSD

Das hilft aber nur solange die SSD angeschlossen und im Betrieb ist.

Ohne Strom hat auch die beste Firmware keine Chance.

 

[Marcus . R]

@Corpus Delicti Hmmm jährlich wäre mir aber doch deutlich zu wenig. Dann kann ich am ende ja nur sagen "es hat ca. 1 Jahr gedauert". Da würde ich aber schon sagen, dass ein mal in Quartal, ein check sein sollte. Der Test dauert ja zum Glück nicht lange... ich darf es nur nicht vergessen 😬

edit: Hab´s im Kalender eingetragen. Am 15 September guck ich mal, ob sich schon was getan hat.

 

[gymfan]

Die variante mit DD wäre zumindest einfach und erfasst alle Daten. Da muss man sich keinen Kopf machen ob auch die $bitmap und andere ntfs dateien neu geschrieben wurden. Meist dürfte da einfach ein Dateisystemtreiber Dateien sichern und zurückschreiben. Aber gerade die internen Daten des Dateisystems sind doch potentiell alt und noch an der gleichen stelle wie bei deren Erstellung.

Ein vernünftiges Imaging-Programm nutzt untrer Windows VSS, womit alle genutzten Sektorenn des Live-Snapshots geichert werden, falls sie nicht im Backup-Progrmam ausgenommen werden (Swapfile o.Ä.).

Und da ein Systemimage, das mit Acronis/Marium Reflect oder co. geschrieben und auf einen fabrikneue SSD zurück geschrieben wird, auch funktioniert, ist dort alles relevante dabei.

Der SSDReadSpeedTester speichert doch auch eine tsv Datei samt Pfad für die getesteten Dateien. Da muss man immer noch knobeln und ggf. je nach Dateigröße andere Schwellwerte nehmen, aber prinzipiell ist die Info für die getesteten Dateien da.

Das ist sie eindeutig nicht. Mein 2TB VC-Container wurde am 22.06.2020 einmal vollständig geschrieben. Seitdem wurden Teile davon bis einen Tag vor Test geändert und andere wurden seitdem nicht mehr angefasst. Ich weiss jetzt nur, dass die 2TB am Stück mit 512,7 MB/s (1. Durchlauf) oder auch nur 496,9 MB/s (2. Durchlauf) gelesen werdenn konnten. Gilt das aber für jeden Sektor der Datei oder sind dort ein paar fast nicht lesbare Sektoren dabei, 5% die mit 100 MB/s gelesen wurden und 95%, die schneller lesbar sind (max. sind 545 MB/s)? Einzig, wenn die gesamte Datei nur mit 2-5 MB/s lesbar ist wäre klar, dass die SSD ein Problem hat.

Potentiell könnte man noch automatisch alle ungewöhnlich langsamen dateien defragmentieren lassen bevor man sie erneut testet. Ausgehend von Windows+NTFS.

Was will ich bei einer SSD mit Defragmentierung? Die Defragmentierung hilft hier nur indirekt, weil die Dateien neu geschrieben und danach ein TRIM ausgeführt wird.

Wäre es da nicht sinnvoller den Datenträger offline zu testen, Schrittweise auszulesen und dabei die Geschwindigkeit zu messen?

Das hängt halt davon ab, was Windows alles im Hintergrund tut. Im Zweifel muss man ein Linux booten ohne die SSD zu mounten, die SSD Sektor für Sektor lesen und dabei die Geschwindigkeit protokollieren. Am Ende könnte man die Sektoren den Dateien zuordnen. Oder man macht das schon vorher und liest dann auch nur die belegten Sektoren.

 

[Stormfirebird]

Ich weiss jetzt nur, dass die 2TB am Stück mit 512,7 MB/s (1. Durchlauf) oder auch nur 496,9 MB/s (2. Durchlauf) gelesen werdenn konnten. Gilt das aber für jeden Sektor der Datei oder sind dort ein paar fast nicht lesbare Sektoren dabei, 5% die mit 100 MB/s gelesen wurden und 95%, die schneller lesbar sind (max. sind 545 MB/s)?

Was ist jetzt dein Vorschlag oder Fazit? Das Programm ist recht simpel gehalten und kann einfach nicht jeden Fall abdecken, aber muss es dass denn? Übrigens, wenn ich meine SSD (oder generell eig. jede Komponente im PC) Synthetisch teste kommt auch nicht immer 1 zu 1 das gleiche Ergebniss raus, wegen deiner Varianz da im Test.
Mir langt das Programm für einen groben Überblick und für die meisten anderen sollte es das auch.

 

[Bigeagle]

Gilt das aber für jeden Sektor der Datei oder sind dort ein paar fast nicht lesbare Sektoren dabei

Das ist ein wichtiger Punkt den ich ganz übersehen habe. Das macht es dann noch komplizierter.

Was will ich bei einer SSD mit Defragmentierung?

Das gleiche wie bei einer HDD, nur weniger dringend. Bislang war noch jede SSD bei random 4k langsamer als bei sequentiellem lesen. Overhead vom Dateisystem durch zu stark fragmentierte Dateien kommen noch dazu und in extremfällen kann man halt nichts mehr schreiben obwohl es noch gehen sollte.

Im Zweifel muss man ein Linux booten ohne die SSD zu mounten, die SSD Sektor für Sektor lesen und dabei die Geschwindigkeit protokollieren.

Wenn man eine schnelle pcie SSD Sektorweise samt Messung auslesen will muss man sich endgültig Gedanken um die Qualität der Zeitmessung machen. Wie lange dauert ein Kontextwechsel so? ^^

 

[Sje2006]

Meine alte Samsung 830 64 GB SSD ist mit einer 4 Jahre alten Windows 7 Installation nicht mehr die schnellste ...

 

[Capthowdy]

Ich poste es hier der Vollständigkeit halber auch hier nochmal: meine SN850 SSDs sind ebenfalls betroffen. Datein die älter als 4 Monate sind, werden nur noch mit ~300 MB/s gelesen:

 

[Corpus Delicti]

Bei den Modellen die Betroffen sind, scheint es ein generelles FirmWare-Problem bei WD zu sein.

Samsung hat das Problem mit der 840-er Serie gehabt und gelöst.

Tippe hier auf etwas ähnliches, das WD allerdings (noch) abstreitet.

 

[Mimiwurst]

Artikel-Update: Dank zahlreicher Hinweise und Screenshots aus der Community weist vieles darauf hin, dass das Problem nicht generell besteht.

Von User „Corpus Delicti“ stammt noch der Tipp, das Tool DiskFresh zu nutzen, um gegebenenfalls die Speicherzellen der SSD aufzufrischen, ohne Formatieren zu müssen. Das funktioniert offenbar sehr gut.

Die Redaktion bedankt sich an dieser Stelle für die rege Teilnahme zur Untersuchung des demnach nur vereinzelt auftretenden Problems.

Ihr solltet euch vielleicht mal die Hardwarerevisionen und den verbauten NAND der Laufwerke anschauen. Zumindest hier scheint ja nur die FW 401000WD betroffen zu sein. Gibt es denn auch andere Versionen, die Probleme machen?

Hierzu sei gesagt, dass die FW bei WD mehr angibt, als nur die "Firmware".

FW Anfang X... = Sandisk alte Plattform
FW Anfang 4... = WD Plattform
FW Endung RL = Sandisk
FW Endung WD = WD
FW Endung WR = WD Red

Bei manchen Modellen kann man daran auch erkennen, ob es noch Bics3 oder schon Bics4 ist. Meine Vermutung ist, dass 411 noch Bics3 ist und 415 bereits Bics4 enthält, jeweils bezogen auf die Sandisk Ultra 3D 2TB Sata Version.

Es gibt zig Varianten, die alten mitunter ja noch mit mehr DRAM Cache, die neuen mit weniger. Es gab auch eine 2TB SSD Plus (3D TLC), welche vom Layout her einer Ultra 3D 2TB entsprach und die wiederum der 2TB WD Red. FW 411040RL, wie bei der Ultra 2TB. Die Red hatte 411000WR, eben weil es eine Red ist. Bilder vom Layout der Varianten finden sich mitunter bei Mydealz und auch hier im 2TB SSD Plus Thread.
(Die Red hatte eine andere NAND Bezeichnung, als die 3D TLC 2TB Plus, die Leistung war allen Anschein nach identisch.)

Das WD hier nichts unternimmt, wundert mich nicht. WD handhabt das wie bei den Festplatten, zumal Support für eine Problemserie Kosten verursachen würde und die Kunden dann ja merken würden, dass WD Blue nicht mehr ist, als ein Sticker auf zig verschiedenen Produkten - selbst bei gleicher Größe/Schnittstelle.