etking schrieb:
Es spielt keine Rolle, wie die Daten im Flash verteilt sind denn was zählt ist der LBA-Bereich. Sequentielles Schreiben meint immer sequentielles Schreiben im LBA-Bereich, AS-SSD kann ja gar nicht wissen wie die LBA-Blöcke SSD-intern gemappt sind. Defragmentierung bringt daher gegenüber extremster Fragmentierung einen erheblichen Performance-Vorteil, dieser ist exakt so groß wie der Unterschied zwischen AS-SSD 4k und sequentiellen Lese-Werten. Hinzu kommt der geringere Overhead durch die Dateisystemverwaltung unter Windows, denn ein Fragment veraltet sich deutlich leichter als tausende und schont die CPU.
Das gilt so aber nur, wenn die Datei wirklich so viele Fragment hat wie die Cluster belegt und wie Du schon schreibst:
etking schrieb:
Nur kommt extremste Fragmentierung (alle Dateien sind in einzelne 4K-Blöcke zerhackt gespeichert) so gut wie nie vor, es gibt immer Sequenzen aus mehreren zusammenhängenden 4k-Blöcken.
Eben und gut Controller merken sich eben auch, wie lang die Sequenzen waren, mit einem Befehl geschrieben wurden und verteilt diese Daten dann auch nach Möglichkeit immer so über die ganze Kanäle, dass diese Sequenz eben auch schnell geschrieben und auch wieder gelesen werden kann. Controller die sowas nicht machen sind zwar ehrheblich einfach, bieten dann eben auch nur eine sehr inkonstante Performance, wie es PHISON.
etking schrieb:
Und die GC bzw. interne Verwaltung der SSD kann tatsächlich dazwischenfunken, der genaue Effekt lässt sich nicht abschätzen, weil die Hersteller die exakte Funktionsweise der Firmwares nicht offenlegen.
Wie gesagt, gute SSD Controller wissen welche LBAs zusammenhängen weil diese zusammen geschrieben wurden und berücksichtigen das auch bei der GC. Wird das jetzt in Blöcken zu 4k oder 16k defragmentiert, so geht diese Zusammenhang kaputt und der Controller kann die Verteilung der Controller kann diese eben bei der Verteilung der Daten im NAND nicht mehr berücksichtigen.
etking schrieb:
Zum oben genannten Tuning, es wird behauptet Trim würde keine teilweise belegten Blöcke erfassen, daher werden diese vermieden oder die Daten darin konzentriert. Ob das wirklich etwas bringt, lässt sich nicht wirklich abschätzen aber die paar halbvollen Blöcke dürften in der Masse der SSD nicht ins Gewicht fallen.
Wenn man unter Blöcken die Flashblöcke (kleines löschbare Einheit) von üblicherweise 128/256/512 Pages versteht, dann frage ich mich mal, wie die Software denn wissen will, in welchen Pages und damit Blöcken der Controller die Daten denn nun konkret ablegt. Das weiß nur der Controller und der verrät es nicht. Nur weil man die LBAs in Blockgrößen einteilt, wie sie bei SSDs üblich sind (dei konkrete Blockgröße der verwendeten NAND kann man ja bestenfalls aus dem Datenblat der NANDs erfahren und welche NANDs nun genau verbaut sind, erfährt man oft auch überhaupt nicht) und die Daten dan entsprechend sortiert, hat das keinen Einfluss auf die Anordnung der Daten im Flash.
Außerdem hat TRIM mit der Erfassung von Blöcken nicht zu tun. TRIM ist auch nicht Teil der FW einer SSD. TRIM ist ein SATA Kommando, welches dem Controller anzeigt, welche LBAs nun nicht mehr mit gültigen Daten belegt sind. Das erfährt der Controller sonst erst, wenn diese erneut beschrieben werden. Woher auch immer der Controller es erfahren hat, die Garbage Collection muß entweder im Idle oder beim Schreiben großer Datenmengen regelmäßig die Blöcke auswählen, bei denen der Anteil an Pages mit ungültigen Daten im Verhltnis zu den unbenutzten Pages plus denen mit noch gültigen Daten besonders hoch ist, die gültigen Daten in Pages anderer Blöcke kopieren und den Block flashen.
Nur so steht wieder freier Flashspeicher zum Schreiben von Daten zur Verfügung. Wer also behauptet, diese oder jede SSD hätte keine GC, der soll doch mal erklären, was passiert wenn die Nutzerkapazität erstmalig vollgeschrieben wurde. Das Kopieren der Pages mit noch gültigen Daten erzeugt übrigens die Write Amplification, je weniger gültigen Daten also kopiert werden, umso geringer ist die WA. Der Sandforce versucht die WA möglichst gering zu halten und flasht daher den Speicher immer erst, wenn geschrieben wird, weshalb der auch diesen Einbruch bei der Schreibrate hat, wenn die Flashpages erstmalig beschrieben wurden. Sinnvoll finde ich das nicht, denn wenn keine gültigen Daten mehr in eiinem Block stehen, dann gibt es keine WA und man könnte den Block auch früher flashen ohne irgendwelche Einbussen in der Lebensdauer der SSD zu haben.
