Ja genau, aber überlege doch mal, wie es das machen soll. Seine Aufgabe ist es für frisch geflashte Bereiche zu sorgen, damit nicht erst beim Schreiben der Daten geflasht werden muß, weil das dann langsam wird. Nun kann es aber nur ganze Cells flashen, so typischerweise 32 bis 128 Pages (typ. 4k). Nach einiger Zeit werden zwangsläufig in der Page Daten liegen, die zu verschiedenen Dateien gehören. Einige davon werden weiterhin benötigt und andere nicht mehr, weil die Datei eben schon gelöscht wurde.mumpel schrieb:Dafür ist die GC verantwortlich.
Mit TRIM ist es einfach diese zu kennen, aber ohne TRIM? Wie soll GC da seiner Verantwortung nachkommen können?
Es greift eben einfach zu kurz wenn man sich sagt, dafür ist GC verantwortlich, das macht das schon und deshalb bleibt die Performance immer gleich. Stell Dir einfach mal vor, Du müßtest diese GC selbst schreiben, dann kannst Du auch verstehen, was es leisten kann und was nicht, wann es wichtig ist und wann nicht.
Nein und das habe ich auch niemals behauptet, Probleme treten erst auf, wenn man die SSD einmal komplett voll geschrieben hat, weil dann das GC eben nur noch die Spare Area als freien Platz zur Verfügung hat und wenn man dann mehr Daten schreibt als Spare Area zur Verfügung stand, dann geht die Schreibgeschwindigkeit runter. Denn nachdem dieser freie Bereich voll ist, muß der Controller erst mal sehen, welche Sektoren jetzt eigentlich beschrieben werden / gerade wurden, kann die Cellls mit den Pages in denen die Daten dieser Sektoren leeren (und muß dabei ggf. noch gültige Daten umkopieren) um dann weiterschreiben zu können. Danach kann GC wieder aufräumen und wieder soviel freien Platz zur Verfügung stellen. wie es an Spare Area hat, aber nicht mehr.mumpel schrieb:Überleg doch mal: Es gibt mehrere Szenarien, wo TRIM nicht funktioniert (XP, Vista, OS X, IDE-Modus, RAID, SSD unterstützt gar kein TRIM usw.) - eigentlich gibt es nur ein Szenario wie TRIM funktioniert: Windows 7/Linux ab Kernel v2.6.33 + AHCI-Modus + SSD mit TRIM-Support. Meinst du, deren SSDs sind nach einmaligem Beschreiben (performancetechnisch) im Arsch?
Spare Area in diesem Sinne ist nur die vom Hersteller vorgesehene Spare Area sondern auch alle niemals beschriebenen Sektoren der SSD. Stelle Dir eine HDD vor deren Datensekoren beim Formatieren alle mit Nullen gefüllt werden. Alle Sektoren die immer noch mit Nullen gefüllt seid weil sie niemals beschrieben wurden, zählen dann dazu.
War Deine SSD jemals 100% gefüllt, also ohne freie Bytes mehr? Wohl kaum. Es geht nicht um die Datenmenge die in der Zeit geschieben wurde, es geht gewissenmaßen um den Hochwasserpegel.mumpel schrieb:Auf keinen Fall! Ich habe hier bspw. eine Intel x25-m G1 ohne TRIM-Support, im IDE-Modus unter XP als System-Disk seit ~2 Jahren am laufen. Die Performance ist wie im ersten Tag, kein MB/s Unterschied. Und jetzt komm' mir nicht, dass ich die 80 GB noch nicht voll geschrieben habe
Wäre dem nicht so, gäbe es nicht Tools wie Secure Erease die SSD Nutzer zum Wiederherstellen der Ausgangsleistung verwenden, weil sie die sonst nicht mehr erreichen. Solche Tools sagen dem Controller ganz einfach: Mach mal alles weg und damit ist die SSD auch für ihn wieder komplett leer. Könnte der Controller bzw. sein GC Algorithmus das irgendwie anders hinbekommen, dann bräuchte man solche Tools nicht bzw. sie hätten keinen Nutzen.
Wenn Deine X25M keinerlei Performanceeinbrüche beim Schreiben zeigt, dann schreibst Du nie mehr als Dein Controller auf Deiner SSD immer an freiem Bereich zur Verfügung stellen kann und dann hat das Fehlen von TRIM nur Auswirkungen auf die Lebensdauer, aber bei denen 50nm NANDs solltest Du die nicht spüren können.