juenger schrieb:
Warum sollte die GC bei einer zig MB oder GB grossen Datei, diese umlagern?
Wie soll denn sonst Wear Leveling funktionieren? Stell Dir vor Du kaufst eine neue SSD, installierst da etliche GB an Windows und Programme, die sich praktisch nie ändern. Dann schreibst Du immer wieder auf dem Rest der SSD und nutzt damit nur die anderen Blöcke, die nicht mit den installierten Programmen belegt sind, während diese niemals gelöscht werden, also gar nicht verschleißen? Das wäre extrem ungeschickt und wird von guten Controllern auch erfolgreich vermieden, indem sie diese statischen Daten immer wieder mal intern auf Blöcke umkopieren, die schon relativ zu den anderen sehr viel P/E Zyklen runter haben, damit dann die bisher relativ wenig genutzten Blöcke auch abnutzen und das nennt man Wear-Leveling.
Die Daten werden also sehr wohl umkopiert, nur passiert dabei offenbar ein Fehler. Wenn sie geschrieben werden, landen die gut Verteile in Die1 Page1, Die2 Page1, Die3 Page1, etc. und beim Kopieren dann in Die7 Page 10, Die 7 Page 11, Die 7 Page 12 etc. und daher wird das Lesen langsam, weil nicht innerhalb eines Die parallel gelesen werden kann.
juenger schrieb:
Verstehe ich ehrlich nicht so ganz, da die GC ja mehr kleine Dateifragmente bzw. auf Flash-Ebene Pages zusammenklaubt.
Ein Contoller einer SSD kennt keine Dateien, also auch keine Dateifragmente, der weiß allenfalls welche Daten von welchen LBAs zusammenhängend geschrieben wurden, mehr nicht. Die Flash Pages klaubt auch nicht zusammen, denn da ja immer ganz Blöcke gelöscht werden und das dann vielleicht 256/512 Pages zu je 8k/16k, je nach NAND, also locker 2MiB oder mehr. Diese wird er dann auch wieder alle der Reihe nach beschreiben und zwar sollte das über die Kanäle verteilt passieren. Der lässt da keine einzelnen Pages zwischendurch frei und beginnt einen anderen Block auf dem gleichen NAND Die, das wäre ja Wahnsinn dann noch die freien Pages alle zu verwalten und es wäre dem auch kontraproduktiv für die Haltbarkeit, denn wenn die anderen Daten schon wieder ungültig sind, würde man den Block ja sinnvollerweise wieder löschen und wenn dann noch Pages davon nicht beschrieben worden sind, bekommen die nur unnötig einen weiteren Löschzyklus ohne überhaupt benutzt worden zu sein.
juenger schrieb:
Persönlich denke ich bei dem Thema eher an Dataretention, und einem eher aufwendigen Wiederherstellungsprozess der ECC Recovery.
Das hatte ich auch erst überlegt, im Hinblick auf Low Density Parity Check (LDPC) error-correction, aber einmal ist das je nach Ausführung auch verdammt performant, das 10GBit Ethernet nutzt das ja auch und dann sind die SSDs zu neu und die Zeit ist zu kurz. Die müssen nach JEDEC JESD 218 ja 12 Monate Daten Retention Time bei 30°C haben und das bis zum Erreichen der spezifizierten P/E Zyklen / TBW. Da sind die betroffenen SSDs hier wohl noch ganz weit von entfernt und außerdem fällt die DRT und steigt die Bit Fehlerraten auch mit der Anzahl der verbrauchten Zyklen, was aber nicht linear geht.
Das sieht man auch an diesem Diagramm zur Uncorrectable Bit Error Rate (UBER), die ja anders als bei HDDs bei kaum einer SSD angegeben ist:
Die ist am Anfang ganz gering, praktisch nicht vorhanden und steigt dann aber gegen Lebensende der NANDs massiv an, weshalb es auch schwer da einen Wert zu definieren, anders als bei HDDs wo diese praktisch linear verläuft. Intel hat folgenden Weg gewählt, vielleicht ist der auch irgendwo genormt:
(
Quelle)
Daher glaube ich nicht an Bitfehler und eine so erhöhten Aufwand zu deren Korrektur, aber wie können ihr das jetzt testen, ich habe ja keine Evo? Am Besten indem man die alten Dateien auffrischt, das haben ja wohl sowieso schon alle gemacht, z.B. durch defragmentieren und dann auf dem freien Bereich mächtig viel schreibt und löscht um die GC auszulösen. Das kann man z.B. mit
Anvil's Storage Utilities oder
h2testw machen und wenn man dann ein paar TB geschrieben hat, testet man die Lesegeschwindigkeit der alten Dateien erneut. Das liegen ja dann nur Tage dazwischen und wenn diese nun wieder langsam gelesen werden, fällt wohl die Data Retention als Grund weg, was man auch noch mit einer Gegenprobe bestätigen kann, indem man sie wieder auffrischt und dann gar nichts auf die SSD schreibt und nach der gleichen Zeit erneut die Lesegeschwindigkeit prüft. Wenn es dann die Data Retention ist, müssten die Werte mindestens gleich schlecht sein, da die NANDs nun ja nicht ein verbrauchter sind. Sind die Werte aber besser, so dürfte meine Theorie des "Bugs" in der GC richtig sein.
):
