Technisch ist die ganze Sache bei weitem nicht so eindeutig wie manche es hier darstellen da es unzählige Gründe gibt die zu geringer Lesegeschwindigkeit führen.
TL;DR: Problem mag real sein, aber mit den hier gezeigten Messungen alles andere als eindeutig belegbar.
SSD Read Speed Tester arbeitet auf Dateisystemebene. Es gibt keine direkte Abhängigkeit zwischen Dateisystemdatum einer Datei und dem Alter der eigentlichen Daten im Flash. Die Daten könnten durch die FW schon hundertmal refreshed worden sein und sieht man nicht im Dateisystem. Dazu kommt die Abhängigkeit von der Dateigröße. Kleine Dateien werden mit wesentlich geringer Datenrate bearbeitet als Große. Hat hier natürlich nichts mit umherspringenden Leseköpfen wie bei einer HDD zu tun, sondern mit dem Overhead den das Dateisystem generiert durch die Verwaltungsarbeit wie z.B. Prüfen der Zugriffsberechtigungen, Aktualisieren der Metadaten etc. Bei kleinen Dateien im KB Bereich und Leseraten der SSD im GB/s Bereich, ist dieser Overhead riesig im Vergleich zu der Zeit den das eigentliche Lesen der eigentlichen Daten benötigt und drück massiv auf die effektiven Datenraten. Das alles führt dazu, dass man bei den Messungen mit SSD Read Speed Tester ganz genau gucken muss, welche Schlüsse man auf den Messwerten zieht.
Dazu zeigen SSDs ein Verhalten das es bei HDDs so nicht gibt: Die Lesegeschwindigkeit hat eine Abhängigkeit davon wie die Daten geschrieben wurden. (Für eine detailierte Beschreibung siehe z.B. hier [AN2103de_Performance_tests.pdf] eine Technote von Swissbit, einem Hersteller von SSDs). 10 GB Daten die sequenziell in großen Blöcken geschrieben wurden lassen sich schön zügig lesen, die FW hat kaum Aufwand die Flashblöcke den logischen Adressen zuzuordnen da diese auch in den Verwaltungsdaten schön hintereinander liegen. 10 GB Daten die komplett random in kleinen Blöcken geschrieben wurden (z.B. vorallokierter Speicher der nur durch ein Programm immer wieder geändert wird an bestimmten Stellen wie z.B. Datenbanken es machen) erzeugen dagegen einen riesen Aufwand beim Lesen. Die FW springt nur hin und her in den Verwaltungsdaten für jeden kleinen Block und muss jeden kleinen Block einzeln aufsuchen. Das drückt massiv auf die Datenrate, selbst wenn in beiden fällen vollkommen gleichartig gelesen wird.
Zum eigentlichen Refreshen der Daten durch die FW: Es gibt verschiedene Trigger die die Hersteller spezifizieren können. Menge der gelesenen und geschriebenen Daten, Einschaltzyklen, Anzahl von ECC Fehlern etc. Das ist komplett transparent für den User (muss es auch nicht interessieren) und kann dazu führen das bei einem User Daten refreshed wurden und er keine Probleme sieht, während ein anderer User langsame Datenraten sieht nur weil er einen der Trigger nicht ausgelöst hat und z.B. die Platte weniger oft vom Strom getrennt hat.
Das waren jetzt drei Beispiele die die Datenraten beeinflussen, wo in den bisherigen Betrachtungen hier aber überhaupt nicht berücksichtigt werden. Und der Mangel an Möglichkeiten für einen Enduser verwertbare Analysedaten zu liefern ist mit ein Grund warum ein Hersteller erstmal ga rnichts damit anfangen kann wenn User einfach nur von langsamen Datenraten berichten.
