wann wird der automatische Trimm Befehl ausgelöst?

[°^°M-Power°^°]

Windows 7 soll ja automatisch Trimm´en

wann genau wird denn dieser befehl automatisch ausgelöst?

 

[°^°M-Power°^°]

also während des betriebes nie? dann müllt sie sich zu?

oder meinst du wen ich etwas von der ssd lösche wie bilder usw?

 

[nsa666]

Ja aber nicht sofort bei jeder Datei, sondern dann wenns annimmt dass die SSD gerade nichts zu tun hat. Also meistens paar Sekunden nachdem dateien gelöscht wurden.

 

[Hadan_P]

Soweit ich ich mich erinnere wird Trim ausgelöst wenn der Datenträger zu mehr als 2/3 voll ist und man den Papierkorb leert.

Nicht schlagen wenns falsch ist, ich finde die News grade nicht wo das drinstand

mfg
Hadan

 

[HisN]

Ich würde auch sagen beim Papierkorb löschen, man merkt bei einem Trim-Laufwerk eine kleine Denk-Pause die bei einem Nicht-Trim-Laufwerk so nicht vorkommt.

 

[antiram]

Beim Ultradrive konnte ich es deutlich wahrnehmen, wenn ich den Explorer nach löschen durchkämmt habe, bei der intel merke ich das deutlich weniger...

Bei Indilinx 1819 verständlich (lagt bei unmittelbar aufeinanderfolgenden trims), aber ist das auch bei 1916 so?

Beim löschen von zb. ca. 300MB kleiner Dateien wird 3-4min lang alle 10s ein trim rausgeschickt, das bis zu 512 Teilbereiche (mehr kann die Intel nicht) löscht (zb. sektor 8-16, 64-96 usw.). Deshalb wärs besser wenn man w7 nach größeren Löschaktionen nicht gleich runterfährt. Das nächste Problem ist, daß das ntfs im Laufe der Zeit immer mehr fragmentiert und dadurch die zu trimmenden Teilbereiche tendenziell kleiner werden und sich die ganze trimaktion weiter verzögert.

Wegen den Bugs/Limitierungen bei Indilinx1819/Intel ging das zum W7 release aber nicht besser.

 

[A_H]

Meine Überlegungen gingen dort in eine ähnliche Richtung:

Das nun gerade nicht. Vielleicht schreibt ja das Testprogramm mehrere Dateien gleichzeitig, keine Ahnung. Dein SSD - das unbekannte Wesen.

Ich habe die ca. 55 Testdateien gelöscht und frage mich gerade, wie lange das SSD braucht, den gesamten freigegebene Speicher mit Nullen (TRIM) zu überschreiben, und was wäre, wenn man inzwischen den PC runter fährt oder neu partitioniert und formatiert...

Die Meinungen darauf waren aber anders...

---------- Beitrag hinzugefügt um 16:58 ---------- Vorheriger Beitrag war um 16:49 ----------

Das nächste Problem ist, daß das ntfs im Laufe der Zeit immer mehr fragmentiert und dadurch die zu trimmenden Teilbereiche tendenziell kleiner werden und sich die ganze trimaktion weiter verzögert.

Unter diesem Gesichtspunkt hatte ich schon in Erwägung gezogen, mein SSD doch ab und zu zu defragmentieren. Da man aber nicht weiß, wie und woran sich die Indilinxdinger zugrunde richten...
Jedenfalls beobachte ich die Fragmentierung.

 

[ayn]

quaaaaatsch.

der trick hinter der deallocation im data set management command der ata8 spezifikation - im volksmund trim genannt - hat nichts damit zu tun, dass nullen irgendwohin geschrieben werden beim löschen oder so, sondern dem ssd controler wird mitgeteilt, dass die sektoren x, y und z nicht mehr bönitigt werden woraufhin der controler diese bereiche in seiner free space table als verfügbar flaggt, ende. da wird nichts in die flash-zellen geschrieben oder genullt oder so, sondern der ssd controler weis einfach, dass da nichts mehr liegt und kann die flash zellen behandeln als wären sie frei. dieses commando wird direkt unmittelbar beim löschen einer jeden einzelnen datei und wird mit den anderen commands, die zum löschen notwendig sind, mitgeschickt und unmittelbar umgesetzt. was man eventuell als verzögerung wahrnimmt, sind dann wiederrum irgendwelche garbage collector aktionen seitens der ssd, das kommt dann ganz auf die jeweilige implementierung der hersteller an.

mehr infos dazu gibt es beim at attachment comitee, welches die spezifikationen für ata herausgibt:

Untitled Page

grüße

edit: das ist übrigens auch der grund, warum man auch nachträglich trimmen kann, das OS teilt in den entsprechenden commands einfach mit, welche sektoren alle nicht mit nutzdaten belegt sind und der ssd controler kann das 1:1 so übernehmen. deswegen dauert das auch nur weniger millisekunden. in der regel merkt sich das system ja nicht, welche dateien bereits gelöscht wurden und wo die mal lagen um nachträglich zu trimmen. is ja aber auch nicht notwendig. problematisch wirds natürlich, wenn das os nicht weiß, wo überall nutzdaten liegen, was auch die problematik mit den shadow copy provider erklärt, diese nutzdaten sind für das life-os nicht auf normalen wege sichtbar, damit diese daten nicht nachträglich manipuliert werden können. deswegen waren bei intel nach einen manuellen trim diese datensätze auch im eimer. beholfen hat man sich dadurch, indem man den shadow copy provider startet, schaut, an welchen positionen überall nutzdaten liegen, dann die normalen nutzdaten dazu addiert und diesen datensatz an den ssd controler durchreicht. alles keine magie.

 

[A_H]

@ayn
Und durch diese Untitled Page hast Du Dich komplett durchgewühlt? - Respekt.
Apropos Respekt...
"da wird nichts in die flash-zellen geschrieben oder genullt oder so" Aber ich bitte Dich, denk noch mal nach. Über das, was nach Systemlogik frei ist, entscheidet immer das System. Aus der Sicht brauchte es kein TRIM.

 

[antiram]

bei mein 300MB waren die Dateien im Schnitt 11.5k groß.

Ganz kleine Dateien (bis 1500 Byte) werden in der MFT direkt gespeichert. In der File Allocation Bitmap sind aber alle cluster die zur MFT gehören als belegt markiert, die werden dann sicher auch nie getrimmt.
NTFS: MFT: Master File Table | Windows Profi

dieses commando wird direkt unmittelbar beim löschen einer jeden einzelnen datei und wird mit den anderen commands, die zum löschen notwendig sind, mitgeschickt und unmittelbar umgesetzt.

so wars gedacht, so wurde es in linux eingebaut. Das hat zu lags mit 1819 geführt, war unbenutzbar. Mit 1916 läuft es prima, aber 1916 kam zu spät für w7 release. Deshalb die schräge Lösung bei W7

 

[ayn]

@ayn
Und durch diese Untitled Page hast Du Dich komplett durchgewühlt? - Respekt.
Apropos Respekt...
"da wird nichts in die flash-zellen geschrieben oder genullt oder so" Aber ich bitte Dich, denk noch mal nach. Über das, was nach Systemlogik frei ist, entscheidet immer das System. Aus der Sicht brauchte es kein TRIM.

in dem fall entscheidet der ssd controler, was gesendet wird.

siehe im dokument "e09117r1" read zero after trim bei punkt 4. da steht:

if word xx bit yy of the IDENTIFY DEVICE data is set to one, then the data returned by a read command shall have all words cleared to zero;

dazu muss man jetzt noch ergänzend erwähnen, dass dieses "word xx bit yy of the IDENTIFY DEVICE data is set to one" genau den "getrimmten" zustand der daten kennzeichnet. das quasi die "tabelle" ist, die der ssd controler verwaltet um zu wissen, wo er was noch hinschreiben kann, was er erasen kann, was frei ist, was belegt ist etc.

grüße

edith sagt: windows 7 konnte trim laaaaaange bevor auch nur ein hersteller trim in die firmware seiner produkte eingebaut hat. an den ata commands wird übrigens nicht gerüttelt, die werden 1:1 so umgesetzt wie vom comitee ausgearbeitet. es wäre fatal, wenn da jeder seine eigene wurst braten würde. dafür gibt es ja standards und protokolle in der it welt.

 

[A_H]

In der File Allocation Bitmap sind aber alle cluster die zur MFT gehören als belegt markiert, die werden dann sicher auch nie getrimmt.

Genau daran hatte ich auch schon gedacht. Der zentrale Dreh-und Angelpunkt des Dateisystems ist also anscheinend immer ungetrimmt. In welchen Momenten wird die MFT aktualisiert? Die länger im RAM zu halten, kann doch nicht sinnvoll sein?

Man darf das Thema Timing/Timeout jedenfalls nicht vernachlässigen. Deshalb halte ich es nicht für verkehrt, den blitzschnellen SSDs bei gewissen Operationen doch etwas Zeit zu lassen.

 

[ayn]

dateien in der $MFT werden natürlich nicht getrimmt, nie. die MFT ist für die ssd eine einzige große datei. die datenbank wird von windows verwaltet und gehört zum dateisystem. geschrieben werden dann nullen, wenn man so eine datei löscht. dazu teilt windows den controler mit, dass position n jetzt 0 beinhaltet. und das halt so lange, soviele dateien da drinnen liegen und gelöscht wurden. was aber auch egal ist, weil die $MFT ihre größe beinehält und somit nicht zum free space dazugezählt wird.

grüße

 

[DoubleJ]

da wird nichts in die flash-zellen geschrieben oder genullt oder so, sondern der ssd controler weis einfach, dass da nichts mehr liegt und kann die flash zellen behandeln als wären sie frei.

Das geht nicht, man kann Zellen nicht überschreiben. Vorm Schreiben muss gelöscht werden.

 

[ayn]

aber erst, wenn wieder geschrieben werden muss. beim trimmen nicht notwendig.

 

[DoubleJ]

aber erst, wenn wieder geschrieben werden muss. beim trimmen nicht notwendig.

Aber äußerst sinnvoll. Du willst doch beim Schreiben kein read-modify-write machen müssen, sondern willst direkt schreiben. Sinnvollerweise wird gelöscht (bzw. Blöcke recycled) , sobald der TRIM-Befehl kommt und die SSD nichts zu tun hat.

 

[Cippoli]

Das geht dann in Richtung GC. Kommt auch immer drauf an wie es implementiert wurde.

 

[DoubleJ]

GC und TRIM gehen normalerweise Hand in Hand.

 

[A_H]

Sagen wir doch ganz einfach:

TRIM/trimmen = pflegende Maßnahmen = Arbeit für den Controller (möglichst) dann, wenn das Dateisystem nichts vom SSD verlangt. Dafür müssen die Adressen von nicht (mehr) belegten Sektoren bzw. Zuordnungseinheiten dem SSD mitgeteilt werden.

 

[ayn]

wie das trimmen innerhalb der ssd umgesetzt wurde ist eindeutig und klar geregelt, weil es sich an die ata spezifikationen halten muss, sonst funktionierts nicht.
was jedoch daraufhin vom ssd controler noch veranlasst wird ist komplett herstellerspezifisch. das hat jedoch mit den trim vorgang nichts mehr zu tun und ist einzig und allein im sprachraum des jeweiligen garbage collectors wiederzufinden. trim beschreibt nur, die weitergabe der löschinformationen an die ssd und das dortige ablegen dieser informationen, nicht mehr und auch nicht weniger.

grüße

edit: aber das ist schon sehr speziell geworden mittlerweile
zu der frage, wann denn die daten nun aufgeräumt werden kann man keine ganz klaren aussagen treffen. ich persönlich nehme da keine rücksicht drauf, was der garbage collector wann genau was macht. das weiß ja eh keiner genau außer der hersteller der firmware. jedenfalls warte ich nicht extra mit dem herunterfahren oder sowas. ich zerbreche mir da aber auch keinen kopf bei. trim ist da und läuft, der garbage collector ist normalerweise so ausgelegt, das er immer irgendwie irgendwas macht, solange keine last auf dem device ist (zumindest würde ich ihn so aufziehen), insofern ist alles rund

 

[DoubleJ]

Bei Intel kann man das schon recht gut sagen: Müllt man ein Laufwerk zu, macht danach eine schnellformatierung lässt einen Benchmark über das ganze Laufwerk laufen, ist alles im Ausgangszustand. Der Controller scheint also, sobald er den TRIM-Befehl bekommt, die entsprechenden Bereiche zu löschen (Löschspannung anlegen) bzw. teilweise belegte Blöcke werden zusammengefasst und freigewordene Blöcke kommen in den Pool (das ist der Punkt, an dem TRIM und GC ineinander übergehen).

Der Garbage Collector läuft bei jedem Schreibzugriff mit (macht ja auch Sinn). Kann man auch wieder recht einfach testen: Laufwerk zumüllen, zwei Mal HDTach laufen lassen, beim zweiten Durchlauf hat man fast wieder Ausgangsniveau. Die Blockfragmentierung wird beim sequenziellen Schreiben also sehr wirksam bekämpft.

Siehe dazu auch das Review zur X25-V auf Hardwareluxx, da habe ich Screenshots eingefügt.

Gleiches kann man übrigens auch beim JMF612/618 beobachten.

 

[A_H]

Warum gibt es TRIM? Flashzellen müssen vor dem Wiederbeschreiben in einen Ausgangszustand versetzt werden - entweder unmittelbar vor dem Schreibvorgang, das verzögert selbigen, oder in Ruhephasen des Gerätes. Daraus schließe ich grob, dass die Verzögerung der notwendige Zeitraum für das Trimmen ist. Wenn ich also 20GB auf ein neues SSD in 200 Sekunden schreibe und es dauert bei einem benutzten SSD ohne automatisches Trim 300 Sekunden, dann kann man doch sagen, dass für das Trimmen von 20 GB etwa 100 Sekunden benötigt werden - oder? Dann ist doch zu erwarten, dass wenn ich bei Autotrim 20GB freigebe, das SSD auch etwa 100 Sekunden im Hintergrund beschäftigt ist. Was ist nun, wenn in der Zeit etwas gelesen oder geschrieben werden soll, lässt sich der Controller immer reibungslos unterbrechen? Was macht das Betriebssystem, wenn der Controller sich mal nicht rechtzeitig unterbrechen lässt?

Fast jeder Anwender weiß inzwischen, dass man einen PC geordnet herunter fährt. Rechnen aber alle Betriebssystem damit, dass es neuerdings SSDs gibt, die eventuell manchmal länger als Festplatten mit sich selbst beschäftigt sind?
Hat vielleicht ein schlauer Anwender einen genialen Shutdowntweak angewendet - herunterfahren in 2 Sekunden, es soll ja alles so schön flott gehen. Von gezogenen Netzsteckern ganz zu schweigen. (Ich will jetzt nicht fragen, ob so ein Controller Register hat und ob die immer gesichert werden können.)

So etwas würde ich beim "Plötzlichen Herztod" mancher SSDs nicht ganz ausschließen bzw. umgekehrt, kann ich das durch vernünftiges Verhalten meinerseits vermeiden?!

 

[DoubleJ]

Wenn ich also 20GB auf ein neues SSD in 200 Sekunden schreibe und es dauert bei einem benutzten SSD ohne automatisches Trim 300 Sekunden, dann kann man doch sagen, dass für das Trimmen von 20 GB etwa 100 Sekunden benötigt werden - oder? Dann ist doch zu erwarten, dass wenn ich bei Autotrim 20GB freigebe, das SSD auch etwa 100 Sekunden im Hintergrund beschäftigt ist.

Du stellst hier irgendwelche Zahlen in den Raum, die jeglicher Grundlage entbehren.

Ich habe es inzwischen schon reichlich oft geschrieben, aber mache es auch gerne nochmal: Die meisten Controller, u.a. Intel und JMF618 (dort selbst getestet), benötigen für das TRIMen äußerst wenig Zeit. Belastung, Schnellformatierung, Benchmark direkt hintereinander zeigt bei genannten Controller direkt wieder die Ausgangsleistung. Das Laufwerk muss also in wenigen Sekunden vollständig gesäubert sein. Macht ja auch Sinn, Löschen geht ziemlich schnell (Spannung anlegen, fertig).

 

[TheCritter]

Warum gibt es TRIM? Flashzellen müssen vor dem Wiederbeschreiben in einen Ausgangszustand versetzt werden - entweder unmittelbar vor dem Schreibvorgang, das verzögert selbigen, oder in Ruhephasen des Gerätes.

Das ist zwar richtig was du schriebst dass die erst gelöscht werden müssen bevor die wiederbeschrieben werden können, aber was hat das mit TRIM zu tun?
Also so wie ich es verstanden habe werden die Zellen auf der SSD bei TRIM einfach nur als leer gekennzeichnet, aber nicht gleich gelöscht. Löschen tut glaube der GC wenn der festgestellt hat dass der komplette Block frei geworden ist oder die Daten so zusammengefasst hat und diesen für neue Daten frei gibt.

 

[DoubleJ]

Nun kann der Controller natürlich gleich den Garbage Collector laufen lassen, wenn der TRIM-Befehl ankommt. Es sind prinzipiell schon völlig getrennte Sachen, die aber wie gesagt trotzdem ineinander übergehen und von der Wirkungsweise her nicht scharf zu trennen sind (schließlich läuft der Garbage Collector ja auch, wenn das System garkein TRIM/Discard beherrscht).

 

[ayn]

der garbage collector macht nichts anderes als unter berücksichtigung des wear levelling für die gleichmäßige abnutzung den noch "validen inhalt" also all der inhalt, der nicht mit dem "trim-häkchen" versehen wurde soweit es geht sinnvoll zusammenzufassen, damit möglichst viele komplett freie erase-blocks zur verfügung stehen.

das hat mit trim im sinne von trim nichts zu tun. der garbage collector ist eine vollstädig eigene implementierung und arbeitet unabhängig von trim und hat mit schreibvorgängen auch absolut nichts zu tun, denn:

- ein erase block wird IMMER unmittelbar VOR dem schreibvorgang geleert. sofern da nichts drinnen steht geht das sau schnell, sofern da noch nutzdaten drinnen sind, müssen diese erst ausgelagert werden um dann mit den neuen daten, die in den block sollen gemeinsam nach dem erase in den block geschrieben zu werden -> DAS ruft die verzögerung hervor, nicht das löschen des blocks ansich. wird ein ganzer erase block via trim als frei gekennzeichnet, ist er für die ssd free space und muss und wird auch vom garbage collector nicht weiter gebuffmelt, wozu auch? ist ein per trim als free space geflagter erase block für einen schreibvorgang vorgesehen wird kurz erased - ohne verzögerung (das ist wirklich blitzschnell) - und danach mit den daten, die mittlerweile ja auch alle noch vorgecacht werden befüllt, fertig.

also nochmal:

trim: nur eine kennzeichnung für nicht mehr verwendete daten. ATA standard der generation 8

garbage collector: herstellerspezifische logik innerhalb der firmware, die teilgenutzt erase blocks soweit zusammenfasst, dass unter berücksichtigung des wear levelling möglichst viele komplett leere erase blocks zur verfügung stehen.

erase block: logische einheit aus mehreren datenblöcken, die gemeinsam vor JEDEM schreibvorgang geleert werden müssen. ist ein erase block nicht frei, muss erst der nutzinhalt ausgelesen, zwischengespeichert, mit den dazukommenden inhalt zusammengefasst und nach dem leeren des erase blocks komplett zurückgeschrieben werden.

grüße

 

[TheCritter]

Genau, so hatte ich das auch verstanden. Wusste nur nciht genau ob der GC den Block "vorlöscht" oder vor dem schreiben gelöscht wird. Und das bischen Zeit was zum löschen vor dem schreiben benötigt wird, dazu gibts ja noch den Cache.

 

[ayn]

nene, den GC kannste dir wie ein software WALL-E vorstellen, der "nur" zusammenfasst und lustige stapel baut :]

 

[TheCritter]

Wall-E Der Vergleich gefällt mir. Aber löschen muss der GC ja auch, wenn der einen neuen "Stapel" anfängt.

 

[A_H]

The SSD Anthology: Understanding SSDs and New Drives from OCZ - AnandTech :: Your Source for Hardware Analysis and News

Und das dauert bei ungünstiger Datenverteilung.

OT
dict.cc W

"Adressen übermitteln" kann ich da nicht finden

TRIM bezieht sich also auf den Zweck der Adressübermittlung.