re_sp4wn schrieb:
in jetzt beim Thema War-Leveling und TRIM angelegt, hab mich mal ein wenig schlau gemacht versteh aber den eigentlichen Grund Hinter der Operation nicht.
Ist doch ganz einfach: Im Prinzip kann man NAND Flash erst beschreiben nachdem man einen großen Bereich (Löschblock 256 oder 512kB) vorher gelöscht hat. Die Daten werden aber in kleineren Bereich (Page, 2k, 4k oder 8k) adressiert, also gelesen bzw. geschrieben.
Jedesmal wenn man die einer Page ändern will, muß man die Daten eines Löschblockks (also vieler Pages) löschen, dann man kann nur einen ganzen Löschblock löschen und muß daher alle anderen Pages des Löschblocks vorher woanders hin kopieren, sofern die Daten in diesen Pages noch gebracht werden.
re_sp4wn schrieb:
wie ichs verstanden habe, dient TRIM dazu einzelne Speicherblöcke / Zellen direkt beim löschvorgang zu überschreiben / löschen und nicht eben nur aus Dateisystem zu streichen und freizugeben um sie dann beim kommenden schreibvorgang zu überschreiben.
Richtig, bei einer normalen HDD kann man die Daten Sektorweise (als typisch 512B, heute teilweise 4k) überschreiebn und dies auch so oft man will. Die magnetischen Scheiben erlauben das Ändern des Ausrichtungunbbegrenzt oft. Flash Speicher hat im Gegensatz dazu ein Problem: Man bringt beim Scheiben Elektronen ein und entfernt diese beim Löschen wieder. Dies funktioniert aber nicht immer perfekt und es bleiben mit der Zeit Elekontronen zurück die es irgendwann nicht mehr erlauben den Ladungszustand der Zelle richtig zu erkennen. Bei MLC NAND Flash geht man von 10.000(50nm)/5.000(34nm) 3000(25nm) Löschzyklen aus, bis dies der Fall ist. Allerdings bringen die ersten 25nm NANDs der Serienfertigung sogar nur 1000 Löschzyklen, weshalb viele angekündigte Produkte mit diesen Bausteinen sich noch verschieben. Man sieht auch, dass kleinere Strukuten hier durchaus Nachteile bringen.
re_sp4wn schrieb:
lt dem Artikel bei ht4u.de werden daten aus einem Block in einen "cache" geladen, dann dort verändert und dann erst wieder zurückgeschrieben in den entsprechenden Block.
Das ganze natürlich ohne TRIM
Es wird sehr viel Unsinn über SSDs geschrieben und viele Unwahrheiten werden verbreitet, aus den verschiedensten Grüden. Richtig ist folgendes:
1. Die Controller einer SSD werden versuchen die Abnutzung der Zellen durch Scheiben und Löschen möglichts gleichmäßig zu verteilen, damit nicht einzelen Bereich früh ausfallen und die Kapazität mindern -> Wear Leveling
Dazu übersetzen sie die logischen Adressen (LBA) einer Platten in sich immer wieder ändernde physikalische Adresse des NAND Speichers, weshhalb man SSDs weder defragmentieren noch Dateien durch überschreben sicher löschen kann.
2, Normalerweise markiert nur ein Bit in den Verwaltungsdaten ob eine Datei gelöscht ist oder nicht. Für das Filesystrm ist das Löschen also nichts anderes als das Setzen eines Bits und von daher erfährt der Controller der SSD auch nicht mehr als das irgendwo ein Bit gesetzt wird.
Normalerweise nutzen aber SSDs den Cache nicht für die Nutzdaten sondern nur für Verwaltungsadten wie die Übersetzung der LBAs zu den logischen Adressen. Der Sandforce 1500 nutzt seinen Cache auch für Daten, verlangt aber nach einem leistungsfähigem Kondensator auf der Platine um die Nutzdaten auch bei plötzlichen Stromausfall noch auf das NAND schreiben zu können.
re_sp4wn schrieb:
Mit TRIM sollte es nicht so sein und ich nehme mal an das dann die Daten direkt im Block verändert werden können.
Warum die Umstände ohne TRIM-Befehl? Oo
Kann man die Speicherzellen / Blöcke nich einzeln adressieren und neu schreiben?
Ergo müssten für das verändern eine winzigen Datei gleich 8-16 MB gelesen, geladen, verändert und neu geschrieben werden (?)
Der Unterschied zwischen mit und ohne TRIM ist ganz einfach und im Grunde leicht auf eine Frage reduziert: wann erfährt der Controller der SSD ob die Daten einer Page noch gebraucht werden. Ohne TRIM ist das löschen einer Datei nur das Setzen eines Bits. Die LBAs (Sektoren) die diese Datei belegt sind nun mit eigentlich ungültigen Daten belegt und werden vom File- Betriebssystem irgendwann mit neuen Daten überschrieben. Bei einer HDD spielt dies keine Rolle, denn die Scheiben werden neu magnetisiert, egal was vorher dort stand oder ob die vorher leer waren. Bei einer SSD ist es anders, wennn die entsprechenden Pages nicht leer waren, dann können sie nicht neu beschrieben werden. Man muß vorher auch nicht nur die Page löschen sondern den ganzen Löschblock, als einige Hundert Pages. Löschen dauert aber relativ lange und wenn bei den Hunderten von Pages des Löschblocks noch etliche mit gültigen Daten belegt sind, dann muß man diese vorher woanders hin schrieben, was die Sache noch weiter verzögert.
Deshalb wird der Controller der SSD den neuen Schreibzugriff auf einen schon gelöschten Bereich leken und die Daten dort ablegen. Gleichzeitig weiß er jetzt, dass die Pages der überschriebenen LBAs jetzt keine gültigen Daten mehr ennthalten und er diese Daten also löschen kann und nicht mehr umkopieren muß, wenn er den dazugehörigen Löschblock flaschen will. Ohne TRIM wird er also nur LBAs als ungültig erkennen, wenn sie neu beschrieben werden.
TRIM ist nichts anderes als dem Controller der SSD schon beim Löschen einer Datein die LBAs mituteilen, die von dieser Datein belegt wurden. Das Filesystem kennt diese LBAs, denn wenn es die Dartei lesen will fordert es die Daten in diesen LBAs von der Platte an. TRIM ist also nicht mehr als zu Sagen "Lösche die LBAs xyz" statt Lese die LBAs xyz, weshalb es auch so schwer zu verstehen ist, warum die RAID Controller sich damit so schwer tun dies zu implmentieren.
Was ist der Unterscheid für den Controller der SSD? Es ist der Zeitpunkt ab wann er Daten löschen darf anstatt sie weiterhin beim GC (Garbage Collection) kopieren zu müssen. Ohne TRIM kann er das erst, wenn die LBAs neu beschrieben werden und mit TRIM schon, wenn die Datei die diese belegt hatte, gelöscht wird.
Garbage Collection ist eigentlich der falsche Name, denn es wird nicht der Müll gesammelt sondern gerade die noch wichtigen Daten werden vor dem Löschen kopiert und den Datenmüll entsorgt man durch flashen.
Wieviel dies in der Paxis ausmacht hängt eben stark davon ab, wann ein LBA neu beschrieben wird und wieviel gelöschte aber noch nicht überschriebene Dateien man auf der Platte hat. Schreibt man die SSD einmal komplett voll und löscht alle Dateien danach wieder, so ist die SSD für einen Controller ohne TRIM eben voll und für einen mit TRIM eben leer.
HisN schrieb:
Weil die SSDs über Write-Combining ihre Schreibleistung generieren. Und dafür ist halt leerer Speicher von nöten. Sie bündeln praktisch mehrere Schreib-Zugriffe und schreiben sie dann Blockweise (so wie es Flash am liebsten hat) raus.
Man kann NAND Flash nur in Pages adressieren, sons müss man NOR Bausteine nehmen. Die Pages stind typischierweise 4k oder 8k groß und diie Controller werden eine Datei die in eine Page passt auch immer in eine Page einer Flash Bausteins schreiben und sie erst dann über zwei (oder mehrere) Bausteine verteilen, wenn die eben größer als eine Page ist. Deshalb ist ja auch die Performance bei 4k und NCQ=1 so viel geringer als bei viel größeren Daten.
HisN schrieb:
Nein: Flash kann nicht Zellenweise adressiert werden. Immer Block-Weise. Und wenn man annimmt dass ein Lösch-Block bei billig MLC-Systemen schon mal 1MB groß ist kannst Du Dir ja die Overhead-Leistung beim schreiben von einer Zelle in 1000 Blocks ausrechnen :-)
1MB ist ehr untypisch und Controller die vor dem Schreiben erst mal Löschen müssen sollte es seid dem JM602 (Stotterer) nicht mehr geben. Nicht zuletzt weil alle SSDs auch eine Spare Area dafür haben.
HisN schrieb:
[/QUOTE]
Mehr oder weniger.
re_sp4wn schrieb:
Also ist der eigentliche unterscheid nur das die eigentlich gelöschten daten ohne TRIM trotzdem aus dem block ausgelesen werden, dann verändernt und zurückgeschrieben und mit TRIM das ganze einfach nur in den Block geschrieben wird?
Der Unterschied ist, dass der Controller ohne TRIM erst beim Überschreiben der LBAs einer gelöschten Datei weiß, dass diese wohl schon vorher nicht mehr benötigt wurden und er sie vielleicht trotzdem mehrfach umkopiert hat. Mit TRIM weiß er das eben schon gleich beim Löschen der Datei und kann die entsprechenden Bereiche löschen bzw. braucht sie nicht nicht mehr umzukopieren, wenn sie gelöscht werden.
re_sp4wn schrieb:
Wiki hatte schon bei SSDs nen ziemlich wirren und unstrukturierten aufbau, deswegen hatte ich mir das mit dem NAND-Flash für später aufgehoben
Vergiss WIKI, da steht auch viel Mist drinne, etwa dass moderne SSDs von TRIM nicht mehr profitieren. Belegt mit einem Test hier, der nichts besagt. wenn ich 8 GB einer 128 GB SSD teste und immer wieder die gleichen LBAs beim Test überschreibe, dann ist TRIM in der Tat nicht relevant, denn wenn ich eine Datei überschreibe weiß der Controller auch ohne TRIM, dass die LBAs jetzt ungültige Daten enthalten, egal ob ich ihm das nun beim Löschen via TRIM oder durch das unmmittelbar darauf erfolgende Überschreiben mitteile.
AndrewPoison schrieb:
Theoretisch müssten einem bei SSDs mit Trim dann ja auch die Datenwiederherstellungsmöglichkeiten aus gehen, oder? Weil gelöscht ist gelöscht, nicht nur als zum löschen markiert.
Richtig, aber hier hängt es eben sehr davon ab, wie oder besser wann der Controller die Informationen über die ungültig ggewordenen Blöcke die ihm per TRIM mitgeteilt wurden, verarbeitet. Normalerweise nutzt er diese beim GC, welches er in einem Moment der Ruhe (Idle) durchführt um Löschblöcke in denen nur noch recht wenige oder keine Pages gültige Daten enthalten zu löschen. Hatte die Datei aber einen kompletten Löschblock belgt, so kann er diiesen aber auch sofort flachen und damit ist eine Wiederherstellung dann eben gleich nach dem Löchen schon unmöglich.
palace4d schrieb:
NAND-Flash ist ein serieller Speicher der mittels Kommandos und Adressen per I/O Interface kommuniziert. Auf diesen Interface werden auch Nutzdaten übertragen.
Um eine Page auszulesen oder zu bearbeiten muss diese in das Datenregister transferiert werden. Dies geschieht indem am I/O Interface das Kommando und die Adresse angelegt wird. Dieser Vorgang nimmt 4 Zyklen in Anspruch. Danach erfolgt nach einer gewissen Zeit ,tR, die Ausgabe der Page über das I/O.
Auf einer Page gibt es nur einen möglichen Übergang.
logisch 0 --> logisch 1 (oder logisch 1 --> zu logisch 0, kommt auf den Speicher an, auf jeden Fall nur in eine Richtung)
Die Zellen können bei diesen Vorgang einzeln selektiert werden.
Der Rücksetzen von logisch 1 zu logisch 0 funktioniert jedoch nur, wenn die ganze Page gelöscht wird (Page muss wie oben eingelesen werden). Aufgrund der Gruppierung (AND-Gatter --> Reihenschaltung) ist die kleinste löschbare Einheit ein Block.
Trim löscht die Zellen sofort, da das Löschen weniger zeitkritisch ist als das Schreiben, ergibt sich daraus ein Geschwindigkeitszuwachs.
Das hängt vom controller und den Pages ab, die die Datei belegt hatte. Ein Page ist die kleinste Einheit beim Lesen und Schreiben, aber beim Löschen müssen immer viele Pages (ein Löschblock) auf einmal gelöscht werden und wenn nur einige Page des Löschblocks zu einer gelöschten Datei gehören, dann kann man nicht den ganzen Block löschen ohne die anderen (mit gültigen Daten) belegten Pages vorher wonander hin zu kopieen. Je nachdem wie agressiv das GC arbeiten, wird es einen Löschblock also erst dann wirklich freimachen, wenn entsprechend viele Pages darin schon üngültige Daten enthalten, denn sonst erzeugt einer viel zu viele interne Scheibzyklen (Write Amplification).
mumpel schrieb:
Ohne TRIM weiß die SSD nicht, wenn Daten gelöscht wurden, bis das OS ihr sagt "Dahin speichern". Nun sind aber in dem Datenblock evtl. noch andere Datenfragmente drin, die nicht gelöscht werden sollen. Soll die SSD nun Daten speichern, dann muss sie mühselig on-the-fly die vorhandenen Daten von den gelöschten trennen - und das dauert und verlangsamt die Performance.
Es ist ja die Aufgabe von GC möglichst zu verhindern, dass es On-the-fly passiert und selbst wenn eine SSD sehr voll ist, sind dafür noch immer ein paar freie Bereiche vorgesehen um genau das langsame on-the-fly zu verhindern.
Deframentieren kann man eine SSD überigens nicht und man braucht es auch nicht. Denn die LBA, welche eine Defragmentierprogramm angezeigt bekommt, werden intern immer wieder auf andere Speicherbereiche gemappt. Belegt eine Datei 3 LBAs, so kann die SSD dafür z.B. 1080, 5043, 8889 angeben und das Programm versucht jetzt diese auf 1,2,3 zu verschieben, denn bei einer HDD würde derart weit auseinander liegende LBAs große Kopfbewegungen und damit einen langsamen Zugriff bedeuten. Bei einer SSD ist aber die Zugriff auf alle Pages gleich schnell. Verschiebt das Defrag Programm jetzt die Blöcke, so werden sie nur unnötigerweise in Speicher der SSD kopiert und diese gibt dann die LBAs 1,2,3 aus, obwohl sie intern in ganz anderen Speicherbereichen liegen, denn eine SSD mappt die logischen Sektoren immer auf interne Adressen um. Wäre das nicht so, würden weder Wear-Leveling noch GC funkionieren und vor dem Überschreiben eines bereits gelöschten Sektors müßten alles Daten des dazugehörigen Löschblocks geflasht werden und wäre damit verloren, den ein FS weiß ja nicht, wie groß dieser Block ist und das die Daten erst gelesen werden müssen bevor man auch nur einen Sektor innerhalb einer Löschblocks ändern kann.
