Inwieweit funktioniert TRIM nach einer Unterbrechung bzw. nachträglich?

[Cord]

Hallo liebe CBler,

ich habe mal eine Frage zur TRIM-Funktion auf die ich durch Googeln keine Antwort finde.
Wenn eine SSD intern (mit installiertem Windows 10) betrieben wird, werden durch die TRIM-Funktion soweit ich das verstanden habe gelöschte Dateien sobald eine gewisse Menge erreicht ist und der PC sich im idle befindet "richtig" von der SSD gelöscht, damit die Datenblöcke für Schreibvorgänge wieder bereit sind.

Wenn nun Dateien anderweitig von der SSD gelöscht werden (durch ein LiveSystem oder extern an einem anderen PC etc.), sodass das installierte Windows 10 die Löschung gar nicht "mitbekommt", bleiben diese Bereiche dann von dem TRIM-Prinzip dauerhaft ausgenommen oder erkennt das Betriebssystem dann nachträglich irgendwie, dass sich dort noch zu "trimmende" Datenblöcke befinden?

Gruß

 

[Aduasen]

Das Betriebsystem, welches die Löschung vornimmt, sollte schon selber auch TRIM unterstützen bzw. den Befehl an die SSD weiterleiten.

 

[mennyy]

https://www.computerbase.de/forum/threads/ssd-geloeschte-daten-wirklich-geloescht.1349367/

 

[Grimba]

Warum sollte dein Windows nicht mitbekommen, dass Dateien gelöscht wurden, und was hat das mit TRIM zu tun?

Die Löschung findet doch erstmal, wie bei HDDs auch, im Dateisystem statt, was erstmal nicht physisch ist.
D.h. die entsprechenden Dateien werden aus der Zuordnungstabelle des Dateisystems entfernt. Sie sind aber so gesehen physisch noch vorhanden. Auf einer normalen HDD würden die entsprechend nicht zugeordneten Bereiche einfach irgendwann wieder neu zugeordnet, aber die Daten wären physisch noch vorhanden. So auch auf SSDs.
Welches System die Änderungen am Dateisystem vornimmt, ist egal. Es kann von allen, die es lesen können, nachvollzogen werden.

Bei SSDs ist das zwar etwas komplizerter von der Speicherung her, aber letztendlich macht der TRIM befehl nichts anderes, als dem Controller der SSD mitzuteilen, welche Bereiche zu keinem Dateisystem mehr gehören, bzw. umgekehrt: Welche Bereiche sicher zugeordnet sind, so dass die restlichen vom Controller freigegeben können, bzw. geleert.

 

[Cord]

Danke für die Erläuterungen. Dazu hätte ich nochmal Nachfragen:

Warum sollte dein Windows nicht mitbekommen, dass Dateien gelöscht wurden, und was hat das mit TRIM zu tun?

[…]

Welches System die Änderungen am Dateisystem vornimmt, ist egal. Es kann von allen, die es lesen können, nachvollzogen werden.

Weil es ja zum Zeitpunkt des Löschens nicht lief. D.h. es wird nicht "wissen", ob etwas gelöscht wurde oder einfach nie da war, würde ich meinen?

Bei SSDs ist das zwar etwas komplizerter von der Speicherung her, aber letztendlich macht der TRIM befehl nichts anderes, als dem Controller der SSD mitzuteilen, welche Bereiche zu keinem Dateisystem mehr gehören, bzw. umgekehrt: Welche Bereiche sicher zugeordnet sind, so dass die restlichen vom Controller freigegeben können, bzw. geleert.

Darauf zielt meine Frage ab: Wenn unter dem Windows 10 mit aktiviertem TRIM etwas gelöscht wird, dann wird dem Controller der SSD sofort mitgeteilt, dass die entsprechenden Blöcke wieder freigegeben sind.

Wird aber nun etwas wie in meinem Ausgangspost beschrieben gelöscht (etwa mit einem Live Linux ohne aktiviertes TRIM) - und entsprechend NICHT direkt dem Controller der SSD mitgeteilt, dann ist die Frage, ob beim nächsten Start über Windows 10 dieses dann merkt "oha, da wurde was gelöscht bzw. ist nicht mehr da" und dies dann (nachträglich) auch dem Controller der SSD noch mitteilt.

Gruß

 

[Grimba]

Weil es ja zum Zeitpunkt des Löschens nicht lief. D.h. es wird nicht "wissen", ob etwas gelöscht wurde oder einfach nie da war, würde ich meinen?

Falsch. Windows "sieht" nur das Dateisystem, und nimmt auch nur dort seine änderungen vor. Welches Windows oder Linux oder was auch immer dieses Dateisystem mountet und die Dateien löscht, ist egal. Und daher hat es die Information, die es braucht, um zu sagen, welche Dateien aktuell zum Dateisystem gehören, und welche bereiche demnach folglich frei sind. Wer da was drin gelöscht hat, ist egal. Egal ob HDD oder SSD. Der Controller weiß den Rest, unabhängig vom Betriebsystem. Wenn das Betriebsystem einen TRIM Befehl absetzen kann, weiß der Controller, was er zu tun hat.

Darauf zielt meine Frage ab: Wenn unter dem Windows 10 mit aktiviertem TRIM etwas gelöscht wird, dann wird dem Controller der SSD sofort mitgeteilt, dass die entsprechenden Blöcke wieder freigegeben sind.

Nein, es muss nicht zwingend sofort getrimmt werden, bzw. ist es nicht nötig das zu tun, um zu verhindern, dass der nächste diese Bereiche nicht vergisst. Windows ist es egal, wo die Daten tatsächlich auf der SSD liegen. Das weiß Windows gar nicht. Das managed alles der Controller. Wie gesagt, Windows sieht nur das Dateisystem und kann dem Controller sagen "trim mal! Folgende Dateien gehören aktuell zum Dateisystem."

Was jemand anders nicht getrimmt hat, fliegt dann auch raus. Der Zeitpunkt des Trimmens und das Trimmen sind nicht zwingend an die Löschoperation auf Dateiystemebene gebunden, auch wenn man es, sofern ein ganzer Löschblock freiwürde, durchaus für diesen sinnvoll ist, und dementsprechend dann auch stattfindet. Dennoch: das hat erstmal nichts miteinander zu tun. Nachträgliches TRIMMEN funktioniert daher genausogut.

Wird aber nun etwas wie in meinem Ausgangspost beschrieben gelöscht (etwa mit einem Live Linux ohne aktiviertes TRIM) - und entsprechend NICHT direkt dem Controller der SSD mitgeteilt, dann ist die Frage, ob beim nächsten Start über Windows 10 dieses dann merkt "oha, da wurde was gelöscht bzw. ist nicht mehr da" und dies dann (nachträglich) auch dem Controller der SSD noch mitteilt.

Der Controller kriegt immer alles mit. ALLES setzt letztendlich der Controller um. Jedes OS "löscht" nur Dateien aus der Dateizuordnungstabelle des Dateisystems, oder fügt da was hinzu, oder verschiebt es. Den Rest macht der Controller. Im Explorer gelöscht ist nicht physisch gelöscht.

Als Windows noch kein TRIM konnte, haben die SSD hersteller eigene Software für den TRIM Befehl bereitgestellt. Nach deiner Theorie wäre sowas ja kompletter Blödsinn, denn Windows hätte von Tuten und Blasen keine Ahnung gehabt.

 

[Relict]

Windows oder andere OS lesen, schreiben und verschieben in der selben "Textliste" herum.
Der Controller schaut in Eigenregie rein und gleicht diese Liste physikalisch ab, organisiert wo, was. wie in den Chips oder auf der Magnetplatte umgespeichert oder geleert wird. Der Trim-Befehl von Windows bittet den Controller lediglich: Schau jetzt rein und leg mit einer Bereinigung los.

Ob ein anderes System das Dateisystem zwischenzeitlich beschreibt oder Du die Partition löschst und neu anlegst oder formatierst ist unwesentlich. Denn der Controller richtet sich immer nach der aktuellen Liste, genauso wie Dein Windows. Auch wenn diese leer ist oder fehlt, wird er dann entsprechend alles als gelöscht ansehen und das Werk physikalisch vollenden. Die Entscheidung des Zeitpunktes und der Umfang des Vorganges liegt aber immer beim Controller.

 

[Holt]

bleiben diese Bereiche dann von dem TRIM-Prinzip dauerhaft ausgenommen oder erkennt das Betriebssystem dann nachträglich irgendwie, dass sich dort noch zu "trimmende" Datenblöcke befinden?

Wenn das Betriebssystem unter dem die Dateien gelöscht wurden kein TRIM ausgeführt hat oder es nicht angekommen ist, so hat Windows seit Win 8 neben dem Online TRIM (also dem Ausführen von TRIM direkt während des Löschens einer Datei) auch noch ein Batch TRIM. Dies verbirgt sich unter der SSD Optimierung die im Rahmen des Service läuft der früher nur für das Defragmentieren der Dateien zuständig war und normalerweise einmal pro Woche ausgeführt wird. Dabei wird geschaut welche LBAs zu Dateien gehört haben die gelöscht wurden und noch nicht wiederbelegt wurden und diese werden dann getrimmt. Normalerweise ist das Löschen von Dateien ja nur das Setzen eines Flags in den Metadaten der Datei und diese Metadaten bleiben für gewöhnlich recht lange erhalten, weshalb Undelete- und Recoverytools gelöschte Dateien oft noch lange finden, aber gerade bei SSDs mit TRIM nicht wiederherstellen können bzw. eben nur unbrauchbaren Mist wiederherstellen.

Wer sein Windows also nicht aufgrund veralteter Tipps in angeblichen Optimierungsanleitungen verpfuscht hat, der sollte kein Problem damit haben wenn eine Datei gelöscht wurde ohne das TRIM dabei ausgeführt wurde.

Ergänzung (22. April 2020)

Die Löschung findet doch erstmal, wie bei HDDs auch, im Dateisystem statt, was erstmal nicht physisch ist.
D.h. die entsprechenden Dateien werden aus der Zuordnungstabelle des Dateisystems entfernt. Sie sind aber so gesehen physisch noch vorhanden.

Nein, es wird nur ein Flag in den Metadaten der Datei gesetzt. Mit TRIM wird dann noch geschaut welche LBAs diese Datei belegt hat und diese werden dann getrimmt.

Bei SSDs ist das zwar etwas komplizerter von der Speicherung her, aber letztendlich macht der TRIM befehl nichts anderes, als dem Controller der SSD mitzuteilen, welche Bereiche zu keinem Dateisystem mehr gehören, bzw. umgekehrt: Welche Bereiche sicher zugeordnet sind, so dass die restlichen vom Controller freigegeben können, bzw. geleert.

Umgekehrt (Welche Bereiche sicher zugeordnet sind) schon gleich gar nicht, bei TRIM wird der Controller der SSD darüber informiert welche LBAs Daten enthalten die nicht mehr gültig sind und diese kann er dann löschen um wieder freien Platz zu schaffen. Er kann TRIM Befehle aber auch unter den Tisch fallen lassen, wenn er zu beschäftigt ist.

 

[Grimba]

@Holt ja, da war ich zu grob unterwegs, du hast Recht. Ändert aber nichts am Punkt. Danke für die Richtigstellung.

 

[Cord]

Recht herzlichen Dank für die vielen kompetenten Antworten!

Ich würde das ganze nun noch einmal mit meinen Worten zusammenfassen mit der Bitte um Richtigstellung, wenn was falsch ist

Wird eine Datei von einem Fremdbetriebssystem ohne (Online-)TRIM von einer SSD gelöscht, so wird dies zunächst erst einmal nur in den Metadaten der Datei gesetzt und sonst passiert nichts. (Gilt das für alle Briebssysteme? Linuxe, MacOS,..?)

Wenn nun später das auf der SSD installierte Windows gestartet wird, wird es im Rahmen einer wöchentlichen Optimierung (wenn gerade mal das System im IDLE ist) einen Batch TRIM durchführen. D.h. der Controller bekommt den Auftrag, sämtliche Daten auf LBAs, die zu Dateien gehören, die in ihren Metadaten als gelöscht markiert sind zu bereinigen.

Windows oder andere OS lesen, schreiben und verschieben in der selben "Textliste" herum.
Der Controller schaut in Eigenregie rein und gleicht diese Liste physikalisch ab, organisiert wo, was. wie in den Chips oder auf der Magnetplatte umgespeichert oder geleert wird. Der Trim-Befehl von Windows bittet den Controller lediglich: Schau jetzt rein und leg mit einer Bereinigung los.

Ob ein anderes System das Dateisystem zwischenzeitlich beschreibt oder Du die Partition löschst und neu anlegst oder formatierst ist unwesentlich. Denn der Controller richtet sich immer nach der aktuellen Liste, genauso wie Dein Windows. Auch wenn diese leer ist oder fehlt, wird er dann entsprechend alles als gelöscht ansehen und das Werk physikalisch vollenden. Die Entscheidung des Zeitpunktes und der Umfang des Vorganges liegt aber immer beim Controller.

Was genau meinst du denn mit der "Textliste", ist damit das Dateisystem gemeint? Denn da können ja nicht alle Betriebssysteme alles lesen/bearbeiten. Oder ist damit eine Art "Übersetzungshilfe" des Controllers gemeint, damit OS überhaupt wissen aus welchen Daten welcher LBAs sich diese oder jene Datei zusammensetzt?

 

[Relict]

@Cord
Ich meine damit die Dateizuordnungstabelle, welche das Dateisystem beschreibt.
Das ist bereits die Übersetzungshilfe für beide Seiten, wenn Du so willst. Logical Block Addressing (LBA) ist nichts anderes als ein virtuelles/softwareseitiges Array, eine Art Matrix, worin die Daten logisch verwaltet (adressiert) werden.
Und woraus wiederum der Controller den tatsächlichen physikalischen Speicherort des Datenblocks im Speicherchip mithilfe seines internen Algorithmus berechnet und verarbeitet.

Wenn ein anderes Betriebssystem ein Dateisystem nicht lesen kann, dann ändert es in der Regel nichts daran, sofern der Benutzer es nicht beauftragt, mit bspw. Neupartitionieren, Formatieren etc.
Und wenn das andere OS das Dateisystem lesen und/oder schreiben kann, dann arbeitet es in der selben Dateizuordnungstabelle.

 

[Holt]

Gilt das für alle Briebssysteme? Linuxe, MacOS,..?

Da wird ja davon reden ob Windows dann hinterher trimmt, kann es ja nur um Filesysteme gehen die Windows auch unterstützt, also vor allem NTFS, welches ja auch von vielen anderen OS unterstützt wird und damit ist es dann auch bei denen genau so, dass erstmal nur ein Flag gesetzt wird, wenn eine Datei gelöscht und kein TRIM ausgeführt wird. Was andere OS bei ihren eigenen Filesystemen jeweils machen, müsste man im Einzelnen nachschauen, aber da Windows solche Filesysteme sowieso nicht unterstützt, kann es dann beim nächsten Batch TRIM sowieso nichts damit anfangen.

Ich meine damit die Dateizuordnungstabelle, welche das Dateisystem beschreibt.
Das ist bereits die Übersetzungshilfe für beide Seiten, wenn Du so willst.

Die Dateizuordnungstabelle ist der zentrale Bestandteil des Filesystems und das Filesystem wird vom Betriebssystem verwaltet. Man sagt zwar immer, die Platte hätte z.B. ein NTFS Filesystem, aber damit meint man nur, dass die Datenstrukturen eines NTFS Filesystems auf der Platten (oder genauer einer Partition auf der Platte) stehen.

Die Controller der Platten, egal ob SSD oder HDD, haben selbst keine Ahnung von Partitionen, Filesystemen, Verzeichnissen oder Dateien, sondern die stellen nur eine linearen Adressraum zur Verfügung und speichern dann unter jeder Adresse 512 oder 4096 Bytes ab und da kann man nur einen oder mehrere aufeinanderfolgenden Datensätze lesen oder schreiben und die werden eben über Logische BlockAdressen von 0 bis n adressiert, die LBAs. Vor der Einführung wurden HDDs noch über Cylinder, Head und Sector (CHS) adressiert, dazu musste die Geometrie der Platte bekannt sein und es konnten auch nicht mehr Sektoren auf den äußeren als auf den inneren Spuren untergebracht werden, obwohl der Umfang dort ja größer ist, bis zu doppelt so groß. Um dies auszunutzen und sowieso die Kapazität der Platten als auch die Transferraten auf den äußeren Spuren zu steigern, hat man ja die LBA Adressierung eingeführt und damit obliegt es dem Controller der HDD zu entscheiden auf welchem Cylinder, Head und welcher Spur der jeweilige LBA nun physikalisch liegt.

Bei SSDs gibt es da eine Mappingtabelle wo drin steht auf welcher NAND Adresse auf welchem NAND Die die Daten eines LBA stehen.

Logical Block Addressing (LBA) ist nichts anderes als ein virtuelles/softwareseitiges Array, eine Art Matrix, worin die Daten logisch verwaltet (adressiert) werden.

Das ist keine Matrix, sondern ein linearer Adressraum wie ihn jede HDD und jede SSD bereitstellt und diesen Adressraum aufzuteilen ist Aufgabe des Betriebssystems des Rechners. Die HDDs und SSDs bekommen die ganze Zeit praktisch nur Befehle LBA x und die n nachfolgenden LBA zu Lesen oder zu Schreiben und wissen nichts davon ob diese Daten nun die Daten einer Datei oder Metadaten des Filesystem oder gar die Partitionstabelle sind, dies interessiert sie auch gar nicht.