TRIM und GC: Ein Erklärungsversuch!

Holt

Banned
Registriert
Mai 2010
Beiträge
59.527
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.
 
Zuletzt bearbeitet: (Formatierung & Rechtschreibung)
TRIM und GC helfen auch, wobei die kurze und bündige Erklärung der TRIM-Funktionalität auf Wikipedia für den normalen Computernutzer dicke ausreicht...

Dein Text ist recht nett, allerdings ist er passender für eine Facharbeit oder eine kleine wissenschaftliche Hausarbeit, in der du alleine schon ein Glossar verwendeter Begriffe verwenden kannst. Hier werden so viele Termini genutzt, dass der normale User den Wald vor lauter Bäumen nicht mehr sieht... Meines Erachtens ist er hier fehl am Platze, lediglich die letzten beiden "Abschnitte", quasi dein Fazit, sind nochmal von Nutzen.


Edit: Alleine schon der gefühlte 200x genutzte Begriff "Page" stellt im normalen Sprachgebrauch die Kurzform für Homepage dar. Was sind Flags? Was ist aus der guten alten Dateizuordnungstabelle in SSD-Zeiten geworden? Wer kennt schon den Zusammenhang von Paging, Speichernutzung und co? Fragen über Fragen und ein kleiner Hinweis von mir: Nicht jeder hat das eine oder andere Werk von Tanenbaum gelesen... ;-)
 
Zuletzt bearbeitet:
Erstmal Danke @ Holt,

für deine Mühe, und dafür daß Du dir vielleicht noch die Mühe machst deine Arbeit etwas besser zu formatieren. Inhaltlich sehr gut verständlich (bin aber auch kein Normal-User) und aufschlußreich.

@ alle Nörgler,

wenn man weiterhin Leute, die sich soviel Mühe geben anderen etwas zu erklären nur kritisiert, dann schreiben bald nur noch die, die nichts zu sagen haben.


Mit digitalen Grüßen

:cool_alt: Black Widowmaker :cool_alt:
 
Hoffentlich gefällt die Formatierung nun etwas besser, aber der Sinn war eigentlich, dass alles gelesen werden soll. Wer nur die Hälfte liest, der versteht dann unter Page halt eine Homepage im Internnet und dann eben die Zusammenhänge nicht. Ich habe mich ja bemüht es wirklich einfach zu halten, aber bei einem doch recht komplexen Thema ist das eben nur in Grenzen möglich. Ebenso kann man auf bestimmte Begriffe einfach nicht verzichten und wer wirklich von oben bis unten alles liest, der findet diese ja auch erklärt.
Wer sich also nicht die Mühe gemacht hat, den ganzen Text zu lesen, der sollte sich auch die Mühe sparen, ihn zu kommentieren.
 
@Holt:
Die Formattierung ist nun um ein Vielfaches besser und ich habe mir dir Mühe gemacht, den ganzen Text zu lesen, bevor dies der Fall war. Und um es noch einmal zu sagen: Ich finde ihn nach wie vor recht nett! Dennoch kann ich mir meine Kommentare nicht verkneifen, da sich mir der tiefere Sinn verschließt, ihn hier zu veröffentlichen. (Fachlich ausreichend vorgebildet ist eher ein kleiner Teil der Nutzer.) Hatte dich die Thematik so sehr interessiert, dass du ausgiebig recherchiert hast, um deinen Wissensdurst zu stillen? Und um im Nachhinein anderen die Mühe zu ersparen, hast du deine Ergebnisse hier präsentiert? Oder gab es andere Beweggründe? Wenn man es so nennen will, fehlt mir hier die Intention des Autors, ohne die der Artikel wie ein Fremdkörper in der Masse aller Beiträge hier wirkt. Es ist nichts gegen dich persönlich, aber ein fünfseitiger Auszug aus einem Artikel, der im Spektrum der Wissenschaft veröffentlicht wurde, inmitten einer normalen Bild-Zeitungsausgabe hätte den gleichen Effekt bei mir hervorgerufen: Wie/warum kommt der hierher, ohne dass jemand explizit darum gebeten hat?
 
danke, erst einmal an Holt
ich bin auch kein Oberspezi und habe es jetzt voll verstanden , um was es hier geht. habe seit kurzem eine SSD. an alle Nörgler= warum muss ich dumme Kommentare abgeben, wenn ich schon so schlau bin und alles weis!!!
Ergänzung ()

kann mir bitte jemand hierzu etwas erklären. ist alles ok oder...... was bedeutet gut 91%??
danke im Voraus - Gerhard ;)
 

Anhänge

  • SSD.jpg
    SSD.jpg
    88,9 KB · Aufrufe: 1.354
Gerhard steudtn, es geht hier nicht um S.M.A.R.T. Werte und deren Bedeutung bzw. Interpretation durch bestimmte Programme.
Es ging mir darum einmal das Thema TRIM und GC zusammenzufassen in der Hoffnung etwas Klarheit darüber zu schaffen. Überall im Netz findendet man darüber Mythen und gegensätzlichen Aussagen die dann immer wieder zu den seltsamsten Aussagen hier im Forum führen. Deshalb habe ich das immer mal in verschiedensten Threads versucht dies zu erklären, aber da sich das eben immer wieder im allgemeinen Geschafel verliert, versuche ich es jetzt mal mit der Zusammenfassung hier, auch die ich dann nur noch verlinken muß.
Vielleicht entscheidet sich der Moderator ja auch, die als Sticky für alle oben anzuheften.
 
ist ok, habe ich ja auch so verstanden ;)
hast du trotzdem auch eine Antwort auf meine Frage, bitte :confused_alt:
 
Sehr anschaulich und verständlich erklärt dass sogar ein 1/2 Laie wie ich das versteht.

Danke
 
Zuletzt bearbeitet:
Gerhard steudtn schrieb:
ist ok, habe ich ja auch so verstanden ;)
hast du trotzdem auch eine Antwort auf meine Frage, bitte :confused_alt:
Eigentlich wollte ich Dir in einer PM antworten, aber das ging nicht.
Schau auf E7: SSD verbleibende Lebensdauer 91, da kommen wohl auch die 91% her.
313mal eingeschaltet aber nur 161Stunden (ok, die Angabe war noch nicht endgültig), jedesmal also im Schnitt so etwa eine halbe Stunde. Schreibzugriffe (F1): 0x1C0 dürften 448 GB ensprechen, meine 120GB Vertex2 FW1.25 hat 0x400 (1TB) und steht noch bei 100%. Da Du aber eine frühe Firmware hast, könnte Anzahl der möglichen P/E Zyklen darin geringer angegeben sein. Entweder weil die Flashbausteine wirklich weniger Zyklen aushalten oder weil man vorsichtiger (oder realistischer?) war.

Gibt ja immer wieder Berichte hier, wo sich die Angabe der Restlebensdauer nach einen Firmwareupdate geändert hat. Aus den folgenden Erklärungen kann sich wohl jeder die passenden aussuchen, die er für wahtscheinlich hält bzw. seinen Hersteller fragen:
Die neuen Angaben:
1. beruhen auf neueren Testergebnissen
2. beruhen auf Erfahrungen mit dem Produkt bei den Kunden
3. sind für die SSDs der neueren Fertigung mit anderen NANDs gültig, werden aber beim Update dann eben auch auf älteren übernommen
4. waren eine Vorgabe des Marktings, denn heute nutzen viele User Tools wie SSDLife oder CrystalDiskInfo um diese Angaben auszulesen und tauschen sich darüber aus

Welche Antworten der wohl nicht geben wird, ist auch klar, oder?:evillol:
 
Zuletzt bearbeitet:
Ohne Dir auf den Geist gehen zu wollen, würde ich gerne auch eine Frage stellen.

Habe eine Intel G2 80GB. Plane auf SB (2600k) + 16GB RAM aufzurüsten. Wie sollte ich bezüglich Swap-Datei vorgehen? Auf RAM-Disk auslagern - ist das zuverlässig? Oder keine? Das nächste Problem wäre das Temp-Verzeichnis. Hier die Auslagerung auf eine RAM-Disk scheint mir unmöglich, da vieles im Temp-Verzeichnis gelassen wird, worauf erst nach einem Neustart zugegriffen wird (z.B. beim Ersetzen von System-DLLs). Nach dem Neustart wäre aber eine RAM-Disk (und damit das Temp-Verzeichnis) doch leer oder?

Das Auslagern auf eine HDD würde ja wieder zum Performance-Verlust führen, das ständige Schreiben würde andererseits die SSD stark belasten. Nutze meinen Rechner im Schnitt mehr als 10h am Tag.

Hast Du diesbezüglich auch ein paar Optimierungstipps auf Lager?


Mit digitalen Grüßen

:cool_alt: Black Widowmaker :cool_alt:
 
Also bei 16GB Ram brauchst du defenitiv keine Swap.Wegen dem Temporären Dateien ,du kannst dem Ramdrive auch sagen (je nach Programm) das sie den Inhalt vorm Runterfahren auf der Platte speichern soll und beim Hochfahren spiegelt sie die Daten dann zurück aufs Ramdrive, hast dann natürlich höhere Bootzeiten.Hier im Forum habe ich erst neulich nen Thread bezüglich Ramdrives gelesen, musste mal suchen.Ich habe selber alle Temp und Logordner ins Ram gelegt(benutze aber Linux), dort gibt es getrennt einmal ein normalen Tempordner /tmp und einmal ein Tempordner für Daten die einen Neustart überleben sollen /var/tmp, obwohl gesagt wird das manche Programme zickig reagieren sollen wenn /var/tmp im Ram liegt kann ich das nicht bestätigen, funktioniert alles reibungslos.Aber wie gesagt wie Windows sich verhält kann ich dir nicht sagen.

hier, gefunden: https://www.computerbase.de/forum/threads/ramdisk-bei-neustart-ramdisk-laufwerk-weg.859462/
 
Zuletzt bearbeitet:
Irgendwie verstehe ich Euch manchmal nicht, da kauft ihr eine SSD und wollt möglichst keine Dateien darauf ablegen um ja nichts darauf zu schreiben. Gerade TEMP und Swap profitieren doch von der Geschwindigkeit der SSD sehr stark und deshalb gehören die auch darauf, meine SSD ist für mein System zu beschleunigen und nicht mein System ist dazu da meine SSD zu schonen.
Können wir jetzt bitte diesen Thread auf das Thema TRIM und GC beschränken. Danke!
 
du hast schon Recht, wie ein rohes Ei braucht man ne SSD nicht zu behandeln, ich nutze meine im Prinzip wie vorher meine HDD auch aber ne Ramdisk ist eben nochmal um ein Vielfaches schneller als ne SSD, wenn die SSD damit dann auch noch geschont wird und das System aufgeräumt bleibt, warum nicht;)
 
Zuletzt bearbeitet:
@ Blackwindowsmaker: Temp-Verzeichnis kannst du auch auf eine Ramdisk umleiten. Habe ich seit 9 Monaten so, und es gab noch nicht ein einziges Problem.

@ Topic: Ich habe anscheinend aus unachtsamkeit letzte Woche meine geliebte alte SSD zerschossen :( 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.

Ich vermute, garbage collection hat sie abrauchen lassen? k.p. aber schade, dass die platte aus irgendwelchen Gründen doch so fragil war.
 
@Nothor, sowas kann man im Nachhinein schlecht nachvollziehen. Ein Full Format ist bei einer SSD halt keine gute Idee, denn dabei werden ja alle Sektoren beschrieben um sie zu prüfen. Für Indilinx wird wohl SanityErase empfohlen, das wäre dann die bessere Option gewesen. Wie es auch oben steht, es ist immer besser die Tools vom Hersteller (ob empfohlen oder gemacht) zu nehmen, da diese dem Controller das vollständige Löschen auch so mitteilen bzw. es ja über ihn irgendwie auslösen und nur so bekommt man dann auch die alten Performance wieder, vor allem wenn man kein TRIM hat.
Da es auch SSDs gibt, die TRIM unterstützen, deren Leistung aber trotzdem einbricht und mit solchen Tools wiederhergestellt werden kann, haben diese entweder einen extrem mildes GC oder die TRIM Unterstüztung wurde im Datenblatt konsequenter umgesetzt als in der Firmware des Contollers.
Die ganze SSD Technik ist ja noch sehr neu und jetzt kommt ja eigentlich erst die zweite Generation moderner SSD Controller auf die Markt, die überhaupt TRIM unterstützen, denn weder Indilinx noch Intel haben die zu Beginn getan. An den Grundlagen wie oben beschrieben, ändert das alles aber nichts, denn auch der besten GC Algorithmmus wird keine Glaskugel haben um richtig raten zu können, welche Daten ungültig geworden sind. Das muß ihm weiterhin durch TRIM Kommandos oder Überschreiben des LBAs mitgeteilt werden (die Alternative Filesystemauswertung, deren Risiken und Grenzen stehen im Eingangspost).
 
Holt schrieb:
... Ein Full Format ist bei einer SSD halt keine gute Idee, ... ... ist immer besser die Tools vom Hersteller, da diese dem Controller das vollständige Löschen auch so mitteilen bzw. es ja über ihn irgendwie auslösen und nur so bekommt man dann auch die alten Performance wieder, vor allem wenn man kein TRIM hat.

Wie sieht es mit "üblicher" Partitionierungs- und Image-Software wie Acronis, Paragon Easus und co. aus? Sollte man bei einer SSD etwa darauf verzichten? Bzw welche wäre da am besten?


Mit digitalen Grüßen

:cool_alt: Black Widowmaker :cool_alt:
 
Habe neulich gelesen, im Crucialforum, das die Programme von Paragon nicht schlecht seien, die machen viel spezielle Sachen für SSD´s.Mit deren Backupupprogramm ist auch das Übernehmen deines Aligments kein Problem bzw wird dann das Backup richtig positioniert .
 
Zuletzt bearbeitet:
BlackWidowmaker schrieb:
Wie sieht es mit "üblicher" Partitionierungs- und Image-Software wie Acronis, Paragon Easus und co. aus? Sollte man bei einer SSD etwa darauf verzichten? Bzw welche wäre da am besten?

Diese Image Software kopiert gewöhnlich die kompletten Daten sektorweise von der Disk und schreibt sie dann auch genauso wieder Sektor für Sektor zurück. Das die Daten natürlich nicht genauso wieder im Flashspeicher stehen wie vorher, ist dem Mapping geschuldet und sollte daher nicht überraschen oder stören.

Wichtig ist aber, dass nur die belegten Sektoren kopiert werden, da man sonst ja die ganzen unbelegten Sektoren auch auf die SSD geschrieben werden, und damit im Extremfall die ganze Nutzkapazität der SSD beschrieben wird, wenn das Image der Größe der SSD entspricht. Wenn man das bei der Software nicht einstellen kann, dann sollte man eine andere verwenden oder sie eben nur verwenden, wenn man z.B. ein Image einer 40GB Partition auf eine 120GB SSD schreibt, da dann diese Sektoren ja irgendwann auch wieder überschrieben werden und trotzdem vorher noch reichlich freie Kapazität bleibt.

Stehen in den ungenutzen Sektoren wirklich nur Nullen, so ist es bei einem Controller mit Datenkompression (Sandforce) weniger schlimm diese mitzukopieren, denn er schreibt dann ja kaum Daten ins Flash, steht aber noch alter Datenmüll dort weil das Image z.B. von einer HDD gezogen wurde, so hilft auch die Datenkompression nicht. Da die Dateien ja für das Filesystem schon gelöscht sind, wird auch kein TRIM dafür geschickt. Hier könnten dann nur Optimierer zum nachträglichen Trimmen helfen, wenn sie alle belegten Sektoren des MFT trimmen, die zu keiner Datei mehr gehören. Intels Toolbox bietet sowas, O&O Defrag 14 angeblich auch, wobei ich aber nicht weiß, ob die das wirklich so machen oder einfach nur nach gelöschten Dateieinträgen suchen, die es ja möglicherweise nicht mehr gibt. Das Trimmen kann man sonst nur noch die ganz SSD vollschreiben, die Daten anschliessend löschen und so das TRIM für diese ganzen Sektoren auslösen. Ohne TRIM bringt das natürlich nichts als mehr verbrauchte P/E Zyklen.
 
Zuletzt bearbeitet:
Und noch ein DANKE an Holt!

Wenn das kein sticky wert ist kann man ja gleich BILD lesen...
 
Zurück
Oben