klampf schrieb:
Da die danach auch wieder schnell ist, fallen zwei Theorien raus:
1. Meine, dass es evtl. daran liegt, dass die Files mit einem Imaging-Tool aufgespielt wurden
2. Holts, dass die SSD irgendwie auf Dateien optimiert oder dass er langsame Speed durch hohe Fragmentierung auf Filesystemebene kommt.
Moment, dass die Fragmentierung in Deinem Fall nicht schuld ist, war schon klar und lässt sich ja mit contig -a <file> auch leicht prüfen. Der Test von Hallo32 zeigt nur, dass die Fragmentierung eben durchaus die Performance beeinträchtigen kann, wenn eine Daten extrem fragmentiert ist.
Hier dürfte klar sein das der Controller die Daten mit der Zeit intern so umverteilt, dass die eben nicht mehr gut parallel gelesen werden können und dieser Test mit dd oder auch das Defragmentieren, sind nicht anderes als den Controller dazu zu zwingen die Daten komplett neu zu schreiben. Ob sie wieder auf dem gleichen LBA (wie mit dd) oder auf anderen (beim Defragmentieren) landen, ist dabei egal, sie müssen intern immer in andere Pages geschrieben werden und da das eben mit längere Zugriffen erfolgt, werden sie dabei auch gut verteilt.
Blublah schrieb:
Ich glaube auch nicht dass die normale Fragmentierung die entscheidende Rolle spielt. Ich frage mich eher was bedeutet sequentieller Zugriff bei einer SSD überhaupt?
Das ist ein Zugriff wo bei einem ATA Befehl viel Daten in einen Bereich aufeinander folgender LBAs geschrieben werden. So ein ATA Befehl kann ja einen LBA und die bis zu 2^16 LBAs darauf folgenden auf einmal adressieren, also maximal 32MiB.
Blublah schrieb:
Zum Beispiel kann eine SSD die Daten einer Datei doch schneller lesen, wenn diese über mehrere Speicherchips verteilt sind. Bei einer grossen Leseanfrage kann dann die SSD die aufeinanderfolgenden Daten einer Daten parallel aus verschiedenen Speicherbausteinen im voraus lesen.
Das ist eben die Frage, ob die Evo das bei den alten Daten noch kann, denn dazu müssen sie auch so abgespeichert sein, dass sie wirklich parallel gelesen werden können. Das wurden offenbar als sie mal geschrieben wurden, nur scheint es eben so zu sein, dass die interne GC diese irgendwann so ungeschickt umverteilt, dass es nach einige Zeit nicht mehr geht. Wenn also z.B. die Daten alle in aufeinander folgenden Pages und Blöcken des gleichen NAND Dies landen, dann kann da nichts mehr parallel gelesen werden und dazu passen dann die etwas über 30MB/s, die wohl im Extremfall nur noch erreicht werden. Das scheint ein klarer Fehler in der FW zu sein, wo die GC die falsche Strategie für die interne Verteilung von alten Daten hat. Schon das Wear Leveling erfordert ja, dass auch alte Daten immer mal intern neu geschrieben werden müssen.
klampf schrieb:
Die klassische Lösung ist die eines jeden Raid-0, die Daten werden mit einem festen Muster in festen Stripes/Chunks (Blöcke von Daten fester Größe) auf die Bausteine/Channels verteilt.
Nur ist das bei einem RAID0 eben viel statischer, bei einer SSDs ist das weit dynamischer und eigentlich passiert diese Verteilung dann nur für Daten die am Stück geschrieben werden, also mit einem Befehl.
klampf schrieb:
Ich kann mir dann noch vorstellen, dass da manchmal die Stripes nicht perfekt parallel verteilt werden, sondern aus irgendwelchen Gründen auch mal nicht optimal in einem Chip landen.
Könnte ein Seiteneffekt sein, wenn nur wenig geschrieben oder geändert wird.
Das Gegenteil dürfte der Fall sein, je mehr die SSD beschrieben wird, umso mehr müssen auch intern Daten umkopiert werden und dabei scheint das Problem eben aufzutreten, dass diese nun statt gut über die Dies verteilt eher nur in einem Die hintereinander stehen. Damit können sie eben nicht mehr parallel gelesen werden und deshalb ist das Lesen von den alten Dateien dann langsam und wenn man sie neu schreibt geht es wieder schnell.
War nur ein Scherz - hoffentlich 
