NAND-Flash ist ein serieller Speicher der mittels Kommandos und Adressen über ein Interface kommuniziert. Um eine Page von typischerweise 4kByte oder 8kByte auszulesen oder zu bearbeiten muss am I/O Interface das Kommando und dessen Adresse übertragen werden.
Beim Schreiben von Daten gibt es für die Bits nur einen möglichen Übergang, wobei die Zellen bei diesen Vorgang einzeln selektiert werden können. Das Zurücksetzen geht aufgrund der Gruppierung (AND-Gatter sind eine Reihenschaltung) nicht zellenweise, die kleinste löschbare Einheit ist ein Block von typischerweise 1MByte oder 2MByte. Man kann also nur z.B. 256 Pages gemeinsam löschen.
Da die Anzahl der Schreib-Löschzyklen bei Flash Speicher aber begrenzt ist (typischerweise 3000, 5000, 10000 für MLC, 30.000 eMLC, 100.000 bei SLC aber in jedem Fall vom konkreten Baustein abhängig) und der Speicher danach nicht mehr funktioniert, sollte der Controller der SSD mit diesen Zyklen also sparsam umgehen. Eine der wichtigsten Techniken um sowohl Löschzyklen zu sparen als auch eine gleichmäßige Abnutzung alle vorhandenen Flashzellen und damit keinen schleichenden Kapazitätsverlust der SSD zu erreichen, ist das Mappen (also dynamische Übersetzen) der LBAs (logischen Adressen bzw. Sektoren der Platte) auf physikalische Adressen des Flashspeichers.
Ohne diese Technik müsste ein ganzer Block beim Überschreiben eines LBAs zuerst komplett gelöscht werden um die neuen Daten dort wieder schreiben zu können und da dieser Block 256 Pages umfasst, müssten alle anderen Pages die Daten enthalten vorher ausgelesen und hinterher wieder zurückgeschrieben werden.
Dies würde natürlich extrem lange dauern und zu einem sehr schnellen Aufbrauchen der Löschzyklen führen, denn um alle Pages des Blocks einmal zu überschreiben wären so 256 Löschzyklen nötig. Deshalb werden die neuen Daten des LBA in eine anderen Page geschrieben und der Verweis für den LBA auf die Adresse der anderen Page geändert. Dadurch bleiben aber die alten Daten in der Page zurück und sind nun ungültig, da ja der LBA jetzt einer anderen Page zugewiesen worden ist. Der Controller weiß also durch das Überschreiben des LBAs, dass die Daten in der Page die dem LBA vorher zugewiesen war, ungültig sind! Das ist genau wie bei einer HDD, wo die alten Daten ja nach dem erneuten Schreiben auf die gleiche Adresse auch ungültig (nur halt eben wirklich überschrieben und damit weg) sind.
Durch das Schreiben füllen sich nun immer mehr Pages mit Daten und damit die freien Pages nicht irgendwann ausgehen, muss der Controller aufräumen, denn einige der Pages enthalten ja Daten von inzwischen überschriebenen LBAs, also ungültige Daten. Dieses Aufräumen muss spätestens beim Schreiben gemacht werden, sobald die freien Pages nicht mehr ausreichen um die Daten aufzunehmen und das führt dann eben zu deutlichen Einbrüchen der Schreibrate. Um diese unerwünschten Einbrüche zu vermeiden kann man das Aufräumen auch dann machen, wenn die SSD gerade nicht beschäftigt, also schon mal vorsorglich und damit danach wieder schnell geschrieben werden kann. Dies nennt man Idle Garbage Collection (Idle-GC).
Da das Löschen einzelnen Pages aber leider nicht möglich ist und immer gleich der ganze Block aus 256 Pages gelöscht werden muss, ist es Aufgabe des Controller passende Blöcke zum Löschen auszuwählen. Genau darin und in der Entscheidung, wann überhaupt so ein Aufräumen stattfindet, unterscheiden sind die SSD Controller auch stark. Typischerweise wird der Controller zwei Kriterien für die Auswahl heranziehen: Wie viele Pages des Blocks enthalten noch gültige Daten, die ja vor dem Löschen in andere Pages geschrieben werden müssen (dies erzeugt die Write Amplification) und wie oft wurde dieser Block schon gelöscht (was das Wear Leveling ergibt). Das Wear Leveling ist also keine eigenen Funktion sondern wie die Write Amplification das Ergebnis des Auswahlalgorithmus.
Einige Controller haben eine sehr aggressives Garbage Collection und räumen schon auf, wenn nur ein paar Pages eines Blockes ungültige Daten enthalten. Damit erzeugen sie eine hohe Write Amplification, können aber schnelles Schreiben über den gesamten freien Speicherplatz ermöglichen, da die Blöcke entweder nur Pages mit gültigen Daten enthalten oder gelöscht und damit sofort beschreibbar sind.
Andere Controller löschen hingegen Blöcke erst, wenn auch wirklich alle Pages des Blocks beschrieben wurden oder sonst keine freien Blöcke mehr verfügbar sind. Diese führt zu einer geringen Write Amplification, aber auch dazu, dass selbst Dateien für die genug freier Speicherplatz zur Verfügung steht langsam geschrieben werden, da eben während des Schreibvorgangs erst wieder Blöcke gelöscht werden müssen.
Was ist TRIM und welche Rolle spielt es dabei?
Zunächst mal ist TRIM ein ATA Kommando (UNMAP ist das SCSI Äquivalent), welches das Betriebssystem an den Controller der SSD schickt und dabei LBAs an den Controller übermittelt, so wie auch mit den Befehlen zum Lesen oder Schrieben LBAs übermittelt werden. Die LBAs die mit den TRIM Kommando übertragen werden, sollen aber weder gelesen noch geschrieben werden, vielmehr werden diese vom Betriebssystem für ungültig erklärt.
Warum das ganze?
Da es bei einer HDD keine Rolle spielt, was vor dem Schreiben einer LBA an Informationen in diesem stand, ist das Löschen einer Datei auf Ebene des Filesystems nur ein Eintrag ("Gelöscht Flag") in den Verwaltungsdaten dieser Datei. Es wird beim Löschen also nur ein Bit geändert, mehr nicht. Irgendwann schreibt das Betriebssystem dann wieder auf die Sektoren, die von der gelöschten Datei belegt waren und damit erfährt auch der Controller der SSD davon. Jetzt werden die Daten der Pages die den LBAs zugeordnet waren, auch für ihn ungültig, vorher aber nicht, außer: Ist TRIM aktiv und wird vom OS unterstützt, so sendet es eben das TRIM Kommando für all die LBAs die von der Datei belegt waren. Das OS muss jetzt also nicht mehr nur das Flag in den Verwaltungsdaten setzen, es muss auch die belegten Sektoren ermitteln und an den Controller der SSD übertragen damit der jetzt also schon beim Löschen der Datei die Pages mit deren Daten als ungültig betrachten kann. Da das OS die Sektoren einer Datei ja auch dann ermitteln und übertragen muss, wenn die Datei einmal vollständig gelesen wird, kann der Aufwand TRIM zu implementieren nicht so gigantisch sein.
Wenn er das Filesystem kennt kann der Controller natürlich auch versuchen die Daten auf der SSD selbst zu interpretieren um das Setzen eines "Gelöscht Flags" zu erkennen, die der Datei zugeordneten Sektoren zu finden und diese dann für ungültig zu erklären. Dies stößt aber bei der Vielzahl von Filesystemen auf Grenzen und wird z.B. in RAIDs und bei Cryptographierung schon gleich gar nicht funktionieren. Obendrein birgt es außerdem die Gefahr von Datenverlust etwa aufgrund einer Fehlinterpretation wegen Änderungen des Filessystems oder wegen einer Inkonsistenz im Filesystem. Deshalb ist dies keine wirkliche Alternative zu TRIM und auch nicht verbreitet und soll deswegen hier auch nicht weiter betrachtet werden. Soweit ich weiß hat nur Samsung so etwas mal zu der Zeit implementiert, als TRIM nicht nicht verbreitet und die Samsung SSDs nur für OEMs waren (es gab die Modelle aber für Endkunden als OCZ, Corsair und Kingston) und prompt funktionierten die in RAIDs nicht, weil laufen Fehlinterpretationen passierten und daher die falschen Daten gelöscht wurden.
Was bewirkt TRIM?
TRIM bewirkt also eine Verschiebung des Zeitpunktes wann der Controller Pages als ungültig erkennt, von dem Zeitpunkt des Überschreibens des LBA auf den Zeitpunkt des Löschens der Datei. Damit hat es nur Einfluss auf das Datenvolumen, welches an gelöschten Dateien vorhanden ist, deren Sektoren aber noch nicht überschriebenen wurden. Dies kann im Extremfall die gesamte Nutzkapazität der SSD sein, etwa wenn der User diese einmal vollgeschrieben hat (z.B. um mit h2testw die die neue SSD einmal zu prüfen), selbst wenn er die Dateien danach alle löscht.
Ohne TRIM bleibt die SSD danach für den Controller für immer voller gültiger Daten und ihm steht damit immer nur so viel freier Speicher zur Verfügung, wie die SSD mehr an Flashspeicher als die Kapazität aller mindestens einmal beschriebenen LBAs hat.
Deshalb sollte man eine SSD ohne TRIM niemals ganz voll schreiben und bei SSDs für den professionellen Einsatz wird deshalb auch schon vom Hersteller reichlich Platz freigelassen! Windows hilft nur insofern, als dass es bei NTFS einen Teil (standardmäßig 12.5%) der Kapazität für den MFT reserviert und diesen Platz erst mit anderen Daten beschreibt, wenn keine anderen LBAs mehr verfügbar sind. Sicherer ist es aber, die Partition etwas kleiner zu wählen damit ein Teil der Kapazität garantiert unbeschrieben bleibt.
Wieso bemerken manche User und auch die Autoren mancher Tests keinen Unterschied ob TRIM aktiv ist oder nicht?
Nun, wenn ich eine neue 120GB SSD nehme, 50GB drauf schreibe, diese lösche und dann gleich wieder 50GB schreibe, so war schon vorher Platz für diese neuen Daten frei. Wenn dabei die gleichen LBAs wieder beschrieben wurden, so wird es auch hinterher keinen Unterschied geben, ob TRIM aktiv ist oder nicht, denn beim Überschreiben der LBAs weiß der Controller ja auch ohne TRIM, dass die alten Daten ungültig geworden sind. Ebenso merkt man keinen Unterschied in der Schreibgeschwindigkeit, wenn nicht mehr Daten geschrieben wurde als vorher sowieso an freiem Platz zur Verfügung stand und wenn man mehr schreibt, dann wird das Schreiben mit und ohne TRIM langsamer.
Aber der Unterschied ist halt die Definition von freiem Platz und das ist mit TRIM das, was das Betriebssystem mir anzeigt und ohne TRIM nur die LBAs die noch niemals beschrieben wurden, jeweils plus der Reservekapazität.
Was ist jetzt der Einfluss von TRIM auf die Lebensdauer einer SSD?
Es macht genau diesen Unterschied an dem, was der Controller als freiem Platz ansieht. Diese Daten brauchen nicht mehr in andere Pages geschrieben werden, wenn der Block gelöscht wird in dem sie stehen und die Blöcke in denen sie stehen haben mehr (oder nur noch) Pages mit ungültigen Daten, können also früher gelöscht werden. Mit diesem Datenvolumen steigt also auch der Einfluss von TRIM auf Performance und Lebensdauer einer SSD.
Da das Datenvolumen welches dank TRIM als frei angesehen wird aber eben auch je nach Nutzung der SSD sehr verschieden ist, sind Pauschalisierungen über den Nutzen oder die Notwendigkeit von TRIM absolut fehl am Platz. Man kann immer nur für den Einzelfall sagen, ob TRIM mehr oder weniger viel bringt oder bringen würde. Bei SSDs auf denen keine Dateien gelöscht sondern immer nur überschrieben werden, wie z.B. bei Datenbanken
Wer kein TRIM nutzt und seine SSD schon einmal richtig voll geschrieben hat, der kann z.B. die volle Leistung nur noch mit Tools zum vollständigen Löschen aller Daten die der SSD Hersteller liefert oder benennt, wieder herstellen. Diese Tools löschen die Daten nicht selbst, sondern teilen dem Controller über das Secure Erease ATA Kommando dies selbst zu machen.
Beim Schreiben von Daten gibt es für die Bits nur einen möglichen Übergang, wobei die Zellen bei diesen Vorgang einzeln selektiert werden können. Das Zurücksetzen geht aufgrund der Gruppierung (AND-Gatter sind eine Reihenschaltung) nicht zellenweise, die kleinste löschbare Einheit ist ein Block von typischerweise 1MByte oder 2MByte. Man kann also nur z.B. 256 Pages gemeinsam löschen.
Da die Anzahl der Schreib-Löschzyklen bei Flash Speicher aber begrenzt ist (typischerweise 3000, 5000, 10000 für MLC, 30.000 eMLC, 100.000 bei SLC aber in jedem Fall vom konkreten Baustein abhängig) und der Speicher danach nicht mehr funktioniert, sollte der Controller der SSD mit diesen Zyklen also sparsam umgehen. Eine der wichtigsten Techniken um sowohl Löschzyklen zu sparen als auch eine gleichmäßige Abnutzung alle vorhandenen Flashzellen und damit keinen schleichenden Kapazitätsverlust der SSD zu erreichen, ist das Mappen (also dynamische Übersetzen) der LBAs (logischen Adressen bzw. Sektoren der Platte) auf physikalische Adressen des Flashspeichers.
Ohne diese Technik müsste ein ganzer Block beim Überschreiben eines LBAs zuerst komplett gelöscht werden um die neuen Daten dort wieder schreiben zu können und da dieser Block 256 Pages umfasst, müssten alle anderen Pages die Daten enthalten vorher ausgelesen und hinterher wieder zurückgeschrieben werden.
Dies würde natürlich extrem lange dauern und zu einem sehr schnellen Aufbrauchen der Löschzyklen führen, denn um alle Pages des Blocks einmal zu überschreiben wären so 256 Löschzyklen nötig. Deshalb werden die neuen Daten des LBA in eine anderen Page geschrieben und der Verweis für den LBA auf die Adresse der anderen Page geändert. Dadurch bleiben aber die alten Daten in der Page zurück und sind nun ungültig, da ja der LBA jetzt einer anderen Page zugewiesen worden ist. Der Controller weiß also durch das Überschreiben des LBAs, dass die Daten in der Page die dem LBA vorher zugewiesen war, ungültig sind! Das ist genau wie bei einer HDD, wo die alten Daten ja nach dem erneuten Schreiben auf die gleiche Adresse auch ungültig (nur halt eben wirklich überschrieben und damit weg) sind.
Durch das Schreiben füllen sich nun immer mehr Pages mit Daten und damit die freien Pages nicht irgendwann ausgehen, muss der Controller aufräumen, denn einige der Pages enthalten ja Daten von inzwischen überschriebenen LBAs, also ungültige Daten. Dieses Aufräumen muss spätestens beim Schreiben gemacht werden, sobald die freien Pages nicht mehr ausreichen um die Daten aufzunehmen und das führt dann eben zu deutlichen Einbrüchen der Schreibrate. Um diese unerwünschten Einbrüche zu vermeiden kann man das Aufräumen auch dann machen, wenn die SSD gerade nicht beschäftigt, also schon mal vorsorglich und damit danach wieder schnell geschrieben werden kann. Dies nennt man Idle Garbage Collection (Idle-GC).
Da das Löschen einzelnen Pages aber leider nicht möglich ist und immer gleich der ganze Block aus 256 Pages gelöscht werden muss, ist es Aufgabe des Controller passende Blöcke zum Löschen auszuwählen. Genau darin und in der Entscheidung, wann überhaupt so ein Aufräumen stattfindet, unterscheiden sind die SSD Controller auch stark. Typischerweise wird der Controller zwei Kriterien für die Auswahl heranziehen: Wie viele Pages des Blocks enthalten noch gültige Daten, die ja vor dem Löschen in andere Pages geschrieben werden müssen (dies erzeugt die Write Amplification) und wie oft wurde dieser Block schon gelöscht (was das Wear Leveling ergibt). Das Wear Leveling ist also keine eigenen Funktion sondern wie die Write Amplification das Ergebnis des Auswahlalgorithmus.
Einige Controller haben eine sehr aggressives Garbage Collection und räumen schon auf, wenn nur ein paar Pages eines Blockes ungültige Daten enthalten. Damit erzeugen sie eine hohe Write Amplification, können aber schnelles Schreiben über den gesamten freien Speicherplatz ermöglichen, da die Blöcke entweder nur Pages mit gültigen Daten enthalten oder gelöscht und damit sofort beschreibbar sind.
Andere Controller löschen hingegen Blöcke erst, wenn auch wirklich alle Pages des Blocks beschrieben wurden oder sonst keine freien Blöcke mehr verfügbar sind. Diese führt zu einer geringen Write Amplification, aber auch dazu, dass selbst Dateien für die genug freier Speicherplatz zur Verfügung steht langsam geschrieben werden, da eben während des Schreibvorgangs erst wieder Blöcke gelöscht werden müssen.
Was ist TRIM und welche Rolle spielt es dabei?
Zunächst mal ist TRIM ein ATA Kommando (UNMAP ist das SCSI Äquivalent), welches das Betriebssystem an den Controller der SSD schickt und dabei LBAs an den Controller übermittelt, so wie auch mit den Befehlen zum Lesen oder Schrieben LBAs übermittelt werden. Die LBAs die mit den TRIM Kommando übertragen werden, sollen aber weder gelesen noch geschrieben werden, vielmehr werden diese vom Betriebssystem für ungültig erklärt.
Warum das ganze?
Da es bei einer HDD keine Rolle spielt, was vor dem Schreiben einer LBA an Informationen in diesem stand, ist das Löschen einer Datei auf Ebene des Filesystems nur ein Eintrag ("Gelöscht Flag") in den Verwaltungsdaten dieser Datei. Es wird beim Löschen also nur ein Bit geändert, mehr nicht. Irgendwann schreibt das Betriebssystem dann wieder auf die Sektoren, die von der gelöschten Datei belegt waren und damit erfährt auch der Controller der SSD davon. Jetzt werden die Daten der Pages die den LBAs zugeordnet waren, auch für ihn ungültig, vorher aber nicht, außer: Ist TRIM aktiv und wird vom OS unterstützt, so sendet es eben das TRIM Kommando für all die LBAs die von der Datei belegt waren. Das OS muss jetzt also nicht mehr nur das Flag in den Verwaltungsdaten setzen, es muss auch die belegten Sektoren ermitteln und an den Controller der SSD übertragen damit der jetzt also schon beim Löschen der Datei die Pages mit deren Daten als ungültig betrachten kann. Da das OS die Sektoren einer Datei ja auch dann ermitteln und übertragen muss, wenn die Datei einmal vollständig gelesen wird, kann der Aufwand TRIM zu implementieren nicht so gigantisch sein.
Wenn er das Filesystem kennt kann der Controller natürlich auch versuchen die Daten auf der SSD selbst zu interpretieren um das Setzen eines "Gelöscht Flags" zu erkennen, die der Datei zugeordneten Sektoren zu finden und diese dann für ungültig zu erklären. Dies stößt aber bei der Vielzahl von Filesystemen auf Grenzen und wird z.B. in RAIDs und bei Cryptographierung schon gleich gar nicht funktionieren. Obendrein birgt es außerdem die Gefahr von Datenverlust etwa aufgrund einer Fehlinterpretation wegen Änderungen des Filessystems oder wegen einer Inkonsistenz im Filesystem. Deshalb ist dies keine wirkliche Alternative zu TRIM und auch nicht verbreitet und soll deswegen hier auch nicht weiter betrachtet werden. Soweit ich weiß hat nur Samsung so etwas mal zu der Zeit implementiert, als TRIM nicht nicht verbreitet und die Samsung SSDs nur für OEMs waren (es gab die Modelle aber für Endkunden als OCZ, Corsair und Kingston) und prompt funktionierten die in RAIDs nicht, weil laufen Fehlinterpretationen passierten und daher die falschen Daten gelöscht wurden.
Was bewirkt TRIM?
TRIM bewirkt also eine Verschiebung des Zeitpunktes wann der Controller Pages als ungültig erkennt, von dem Zeitpunkt des Überschreibens des LBA auf den Zeitpunkt des Löschens der Datei. Damit hat es nur Einfluss auf das Datenvolumen, welches an gelöschten Dateien vorhanden ist, deren Sektoren aber noch nicht überschriebenen wurden. Dies kann im Extremfall die gesamte Nutzkapazität der SSD sein, etwa wenn der User diese einmal vollgeschrieben hat (z.B. um mit h2testw die die neue SSD einmal zu prüfen), selbst wenn er die Dateien danach alle löscht.
Ohne TRIM bleibt die SSD danach für den Controller für immer voller gültiger Daten und ihm steht damit immer nur so viel freier Speicher zur Verfügung, wie die SSD mehr an Flashspeicher als die Kapazität aller mindestens einmal beschriebenen LBAs hat.
Deshalb sollte man eine SSD ohne TRIM niemals ganz voll schreiben und bei SSDs für den professionellen Einsatz wird deshalb auch schon vom Hersteller reichlich Platz freigelassen! Windows hilft nur insofern, als dass es bei NTFS einen Teil (standardmäßig 12.5%) der Kapazität für den MFT reserviert und diesen Platz erst mit anderen Daten beschreibt, wenn keine anderen LBAs mehr verfügbar sind. Sicherer ist es aber, die Partition etwas kleiner zu wählen damit ein Teil der Kapazität garantiert unbeschrieben bleibt.
Wieso bemerken manche User und auch die Autoren mancher Tests keinen Unterschied ob TRIM aktiv ist oder nicht?
Nun, wenn ich eine neue 120GB SSD nehme, 50GB drauf schreibe, diese lösche und dann gleich wieder 50GB schreibe, so war schon vorher Platz für diese neuen Daten frei. Wenn dabei die gleichen LBAs wieder beschrieben wurden, so wird es auch hinterher keinen Unterschied geben, ob TRIM aktiv ist oder nicht, denn beim Überschreiben der LBAs weiß der Controller ja auch ohne TRIM, dass die alten Daten ungültig geworden sind. Ebenso merkt man keinen Unterschied in der Schreibgeschwindigkeit, wenn nicht mehr Daten geschrieben wurde als vorher sowieso an freiem Platz zur Verfügung stand und wenn man mehr schreibt, dann wird das Schreiben mit und ohne TRIM langsamer.
Aber der Unterschied ist halt die Definition von freiem Platz und das ist mit TRIM das, was das Betriebssystem mir anzeigt und ohne TRIM nur die LBAs die noch niemals beschrieben wurden, jeweils plus der Reservekapazität.
Was ist jetzt der Einfluss von TRIM auf die Lebensdauer einer SSD?
Es macht genau diesen Unterschied an dem, was der Controller als freiem Platz ansieht. Diese Daten brauchen nicht mehr in andere Pages geschrieben werden, wenn der Block gelöscht wird in dem sie stehen und die Blöcke in denen sie stehen haben mehr (oder nur noch) Pages mit ungültigen Daten, können also früher gelöscht werden. Mit diesem Datenvolumen steigt also auch der Einfluss von TRIM auf Performance und Lebensdauer einer SSD.
Da das Datenvolumen welches dank TRIM als frei angesehen wird aber eben auch je nach Nutzung der SSD sehr verschieden ist, sind Pauschalisierungen über den Nutzen oder die Notwendigkeit von TRIM absolut fehl am Platz. Man kann immer nur für den Einzelfall sagen, ob TRIM mehr oder weniger viel bringt oder bringen würde. Bei SSDs auf denen keine Dateien gelöscht sondern immer nur überschrieben werden, wie z.B. bei Datenbanken
Wer kein TRIM nutzt und seine SSD schon einmal richtig voll geschrieben hat, der kann z.B. die volle Leistung nur noch mit Tools zum vollständigen Löschen aller Daten die der SSD Hersteller liefert oder benennt, wieder herstellen. Diese Tools löschen die Daten nicht selbst, sondern teilen dem Controller über das Secure Erease ATA Kommando dies selbst zu machen.
Zuletzt bearbeitet:
(Formatierung & Rechtschreibung)
Black Widowmaker 
Eine indilinx-SSD, die ich nach nem virenbefall auf dem alten System komplett formatieren wollte. Das tat ich, in dem ich sie über einen usb->sata-adapter an ein zweitsystem anschloss und sie mit windows boardmitteln formatieren ließ (keine Schnellformatierung). Das dauerte über 2 Stunden und musste dann von mir abgebrochen werden da er nicht fertig wurde. Dann habe ich das Laufwerk nochmal per Schnellformatierung auf ntfs formatiert, was auch noch erfolgreich fertig gestellt wurde. Anschließend jedoch beim wiedereinbau in den eigentlichen rechner war die SSD weg. 
