SSD löschen mit Secure Erase - Wie machen und sinnvoll?

[Laggy.NET]

Bei Sandforce SSDs: ja.
Bei allen anderen SSDs: umstritten.
Wichtig ist nur, daß bei SSds Enhanced Secure Erase genommen wird, so, wie es entweder die Hersteller Tools machen, oder wie es PartedMagic anbietet.
Mein RevoDrive 3 X2 und meine G.Skill Phoenix Pro sind nach dem Secure Erase jedes mal wieder genau so schnell, wie fabrikneu. Nach längerer Betriebszeit mit vielen Schreibvorgängen werden sie dann immer langsamer, nur beim Schreiben. Bis zum nächsten Secure Erase. Dieser Effekt ist bei Sandforce SSDs auch seit sehr langer Zeit bekannt und Secure Erase wird dementsprechend selbst von den SSD Herstellern empfohlen.
So viel zum Thema "nicht sinnvoll".
Und dementsprechend bringt es bei Deiner Intel 520 auf jeden Fall etwas.

Und wie lange soll das dann anhalten? Theoretisch sollte die gewonnene Performance ja wieder verpufft sein, wenn alle Zellen mindestens einmal neu beschrieben wurden. Somit dürfte man das ganze alle paar Wochen machen.

Es ist ja völlig klar, dass es nicht ganz unsinnig ist, da es ähnliche Arbeit verrichtet wie TRIM, aber wenn die SSD das auf dauer nicht selbst hinbekommt, ist die methode so oder so nicht sinnvoll.

 

[AdoK]

Das Thema hatten wir schon mal gehabt ...
https://www.computerbase.de/forum/threads/ssd-erase-tools.946933/

und mit anderen Stichworten für die Sufu ist auch noch mehr dazu zu finden ...

 

[SheldonCooper]

So viel zum Thema "nicht sinnvoll".

Ohne jetzt genau zu lesen was du schreibst: willst du mir widersprechen? Denk mal drüber nach welchen Aufwand es bedeutet und was es in der Praxis bringt. Wenn du dann immer noch der Meinung bist, es wäre sinnvoll, dann lass es dir ausführlich von jemand erklären, der es verstanden hat.

 

[Holt]

.........den Datenträger in den Werkszustand zurücksetzt und die SSD damit wieder so schnell macht, wie am ersten Tag

Das trifft bei denen mit Sandforce Controller zu, denn der löscht die Blöcke immer erst beim Schreibvorgang und nie vorher. Deshalb gibt es bei dem einen Neuzustand, wenn noch Zellen vorhanden sind und einen Normalzustand, wenn das nicht mehr der Fall ist und in dem ist die Schreibrate, je nach verbauten NANDs, so 25 bis 40% geringer. Es gibt dann noch einen Recoveryzustand in dem die Schreibrate weiter abfällt, wenn man zu viele Daten in zu kurzer Zeit schreibt, weil er dann beim Schreiben auch noch Aufräumen muss.

Bei allen anderen SSD ist es nur sinnvoll, wenn die nie getrimmt wurden, also der Controller nicht weiß, welche der Daten wirklich noch wichtig sind. Dank Secure Erease weiß er dann, dass er alle löschen muss und damit ist für den Controller die ganze Kapazität wieder frei. Bei getrimmten Platten ist das aber nicht nötig, da reicht es alle Dateien einfach zu löschen.

Ich glaube nicht das bereits abgenutzte Speicherzellen durch das secure erase "widerhergestellt" werden. Man möge mich belehren wenn dem so nicht ist.

Das ist auch nicht so, die P/E Zyklen sind verbraucht und der damit verbundene Verschleiß der Zellen ist nicht reversibel, egal was die S.M.A.R.T. Werte womöglich anzeigen.

Ja, die SSD wird danach schneller, da alle Zellen als "frei" markiert sind. Nach einer Formatierung sind die Daten zwar aus dem Inhaltsverzeichnis gelöscht, aber physisch immer noch in den Speicherzellen vorhanden.

Windows 7 und 8 trimmen nach dem Formatieren die ganze Partition, bis auf die Bereiche mit den Verwaltungsdaten, das ist also so nicht richtig.

Dort müssen sie vor jedem Beschreiben der entsprechenden Zellen entsprechend behandelt werden (Stichwort z.B. MLC).

Was hat das mit MLC zu tun? Ob SLC, MLC oder TLC, bei allen muss vor dem Beschreiben einer Page diese vorher gelöscht worden sein und das geht immer nur blockweise.

Die Frage ist nur, ob man das überhaupt merkt, oder TRIM und/oder GC das Problem schnell genug selbst lösen.

Die GC löscht nur Daten die Adressen zugewiesen waren, die ihr entweder durch das SATA TRIM Kommando mitgeteilt oder überschrieben wurden. Bekommt der Controller keine TRIM Befehle, so können eben nur Daten von LBAs gelöscht werden, die überschrieben wurden. Dann hilft ein Secure Erease, weil es wie ein TRIM über alle LBAs ist und der Controller auch aufgefordert ist, das Löschen sofort durchzuführen.

@ Laggy.NET nimm doch mal ein portables Defrag Tool und mach mal eine Analyse deiner SSD und sag mir dann was raus kam.

Defrag Tool? Man an z.B. mit http://www.mydefrag.com eine Analyse machen, welche LBAs welchen Dateien zugeordnet sind, aber das sagt nichts über die Verteilung der Daten im NAND der SSD aus, denn die Controller mappen intern die LBAs auf immer wieder andere Flashadressen und an diese Tabelle kommt man von außen nicht ran. Das ist also nett um mal zu sehen, was da alles auf der Platte ist, aber sonst bringt es nicht. Denn:

Erstens:
Alle Daten werden wie schon gesagt absichtlich quer über die SSD verteilt, damit eine möglichst gleichmäßige Abnutzung der Zellen gewährleistet wird.

So ist es und nicht nur das, die Daten müssen ja auch so über die Kanäle des Controllers verteilt sein, dass sie parallel und damit schnell gelesen und geschrieben werden können. Würde die einer große Datei wirklich schön hintereinander im gleichen Adressraum stehen, dann wäre der Zugriff darauf viel zu langsam.

Daher ist die fragmentierung absolut irrelevant und sogar gewollt. Das system muss dabei auch nicht mehr "rechnen", falls du meinst, der Aufwand würde durch das suchen und zusammensetzen der fragmente erhöht. Das macht alles der Controller in der SSD.

Moment, da müssen wir jetzt mal unterscheiden:
1.) Die Verteilung der Daten über die Flashadressen ist gewollt und auch von außen nicht einsehbar. Wenn wir aber von Fragmenten der Dateien reden, wie man sie mit einem Defrag-Tool sehen kann, dann ist diese auch bei SSDs ein Nachteil, denn es werden aus wenigen langen und damit schnellen Zugriffen mehrere prinzipiell kürzere und damit langsamere Zugriffe. Aber der Effekt ist i.d.R. so minimal, dass man ihn vernachlässigen kann. Erst wenn man eine viele MB große Daten nun wirklich in Hunderten oder Tausenden kleiner Fragmente von je nur wenigen Clustern Länge vorliegen hat, könnte man ihn wohl überhaupt mal spüren. Bei einer HDD würde man dann aber schon glauben, die hätte einen Defekt weil die nur noch rödelt und keine Daten mehr liefert. Sowas kommt aber in der Praxis eigentlich nicht vor und schon gar nicht, wenn man immer so 10 bis 15% jeder Partition frei lässt.

Und nochmal. Der TRIM befehl sagt der SSD nach jedem Löschvorgang (welche ja nur im Dateisystem bzw. Index stattfindet) dass jene Datei nicht mehr gebraucht wird, wodurch der Controller der SSD diese Speicherzellen wieder als "frei" markieren kann. (<- genau das sorgt dafür, dass die Performance immer konstant bleibt und ist quasi das selbe wie dein Secure erease, nur dass Secure erease eine sinnlose holzhammer methode ist, die nur die Lebenszeit der SSD verringert)

Als frei nicht, denn frei würde bedeuten, es kann dort geschrieben werden, aber vorher muss erst gelöscht werden, denn man kann eben keine beschrieben Page neu beschreiben, nur eine freie. Die werden daher als ungültige Daten markiert und es wird das Mapping der LBAs zur den Daten aufgehoben. Die Idle-GC löscht dann irgendwann den Block in dem diese ungültigen Daten stehen und dann sind sie wirklich weg, aber man kommt schon vorher nicht mehr dran, außer man lötet die NANDs aus. Dabei wählt die GC bzw. Idle-GC eben Blöcke aus, die möglichst weniger P/E Zyklen als der Durchschnitt haben (Wear-Leveling) und die möglicht viele Pages mit ungültigen und wenige mit gütigen Daten enthalten, denn die noch gültigen Daten müssen vorher in eine freie Pages eines anderen Blocks kopiert werden, was die Write Amplification erhöht.

Bei Sandforce SSDs: ja.

Stimmt, aber der Effekt hält nur so lange, bis einmal die Kapazität beschrieben wurde und das kann beim Zurückspielen eines Images dann schon fast der Fall sein.

Bei allen anderen SSDs: umstritten.

S.o! Wenn eine SSD nicht getrimmt wurde, dann macht es Sinn, aber auch dann wieder nur für eine bestimmte Zeit, wenn sie eben auch weiterhin nicht getrimmt wird.

Wichtig ist nur, daß bei SSds Enhanced Secure Erase genommen wird, so, wie es entweder die Hersteller Tools machen, oder wie es PartedMagic anbietet.

Der Unterschied hängt von der Implementierung in der FW ab, denn Secure Erase ist ein SATA Kommando. Es sollte so sein, dass bei Enhanced Secure alle Daten genullt werden und bei Enhanced Secure Erase alle mit einem Muster überschrieben werden, welches der Hersteller vorgibt. Letzteres macht für SSD aber nun wirklich keinen Sinn, aber was konkret passiert, hängt wie schon gesagt von der Implementierung in der FW ab.

 

[0815-TYP]

Und wie lange soll das dann anhalten? Theoretisch sollte die gewonnene Performance ja wieder verpufft sein, wenn alle Zellen mindestens einmal neu beschrieben wurden. Somit dürfte man das ganze alle paar Wochen machen.

Ganz genau.Die Werte werden früher oder später wieder einbrechen.

@ TE

Normale Formatierung reicht.
Daher rate ich von einem Secure Erase / Intel Toolbox ab: http://www.hardwareluxx.de/community/f227/intel-x25-m-g2-postville-im-panikmodus-834145.html

 

[|SoulReaver|]

Ein wilder Beitrag bei Hardwareluxx muss man sagen.

 

[Laggy.NET]

So ist es und nicht nur das, die Daten müssen ja auch so über die Kanäle des Controllers verteilt sein, dass sie parallel und damit schnell gelesen und geschrieben werden können. Würde die einer große Datei wirklich schön hintereinander im gleichen Adressraum stehen, dann wäre der Zugriff darauf viel zu langsam.

Genau das habe ich doch gesagt. Die Daten werden aufgeteilt, damit sie parallel ausgelesen werden können. Vom Prinzip her eben ähnlich wie ein Raid 0 oder DualChannel beim RAM. Daten parrallel auslesen = höhere Geschwindigkeit.

Moment, da müssen wir jetzt mal unterscheiden:
1.) Die Verteilung der Daten über die Flashadressen ist gewollt und auch von außen nicht einsehbar. Wenn wir aber von Fragmenten der Dateien reden, wie man sie mit einem Defrag-Tool sehen kann, dann ist diese auch bei SSDs ein Nachteil, denn es werden aus wenigen langen und damit schnellen Zugriffen mehrere prinzipiell kürzere und damit langsamere Zugriffe. Aber der Effekt ist i.d.R. so minimal, dass man ihn vernachlässigen kann. Erst wenn man eine viele MB große Daten nun wirklich in Hunderten oder Tausenden kleiner Fragmente von je nur wenigen Clustern Länge vorliegen hat, könnte man ihn wohl überhaupt mal spüren. Bei einer HDD würde man dann aber schon glauben, die hätte einen Defekt weil die nur noch rödelt und keine Daten mehr liefert. Sowas kommt aber in der Praxis eigentlich nicht vor und schon gar nicht, wenn man immer so 10 bis 15% jeder Partition frei lässt.

Nun gut, das würde ich mir jetzt so erklären, dass hier wohl der Unterschied darin liegt, dass einerseits das Dateisystem und somit auch das Betriebssystem mitbekommt, dass daten Fragmentiert wurden, was wohl dazu führt, dass die SSD vom System mehrere Anfragen pro Datei bekommt (eben für jedes einzelne Fragment)
und andererseits eben die Verteilung der Daten vom Controller selbst, von dem das System eben nichts mitbekommt, und somit auch die SSD nur entsprechend wenig vom System mit Anfragen zu den einzelnen Teilen der Datei "belästigt" wird.

Gut, hier müsste man wohl tiefer in die Materie einsteigen, aber ich denke, für den TE und viele andere sollte das an der Grundaussage: "Defragmentieren ist sinnlos, da die SSD durch zerstückelte Dateien (sie macht es ja selbst so) keine Geschwindigkeit verliert. " nichts ändern.

Als frei nicht, denn frei würde bedeuten, es kann dort geschrieben werden, aber vorher muss erst gelöscht werden, denn man kann eben keine beschrieben Page neu beschreiben, nur eine freie. Die werden daher als ungültige Daten markiert und es wird das Mapping der LBAs zur den Daten aufgehoben. Die Idle-GC löscht dann irgendwann den Block in dem diese ungültigen Daten stehen und dann sind sie wirklich weg, aber man kommt schon vorher nicht mehr dran, außer man lötet die NANDs aus. Dabei wählt die GC bzw. Idle-GC eben Blöcke aus, die möglichst weniger P/E Zyklen als der Durchschnitt haben (Wear-Leveling) und die möglicht viele Pages mit ungültigen und wenige mit gütigen Daten enthalten, denn die noch gültigen Daten müssen vorher in eine freie Pages eines anderen Blocks kopiert werden, was die Write Amplification erhöht.

Soweit ich das verstanden habe, wird der SSD mit dem TRIM befehl mitgeteilt, welche Dateien bzw. blöcke "frei" geworden sind. Folglich löscht die SSD dank dieser Info nun die entsprechenden Zellen wodruch sie wieder schneller beschrieben werden können.

Gut, meine aussagen sind bei weitem nicht so präzise wie deine. Muss man einfach anerkennen. Da fehlt mir einfach dies Tiefgreifende Wissen. Aber ich denke, im Grunde läufts aufs selbe hinaus.

 

[Holt]

für den TE und viele andere sollte das an der Grundaussage: "Defragmentieren ist sinnlos, da die SSD durch zerstückelte Dateien (sie macht es ja selbst so) keine Geschwindigkeit verliert. " nichts ändern.

Eben, aber halt mit der Einschränkung das dies nur gilt, solange es nicht zu wirklich unrealistisch extremer Fragmentierung kommt. Im Extremfall könnte eine Datei ja in Fragmente von nur je einem Cluster aufgeteilt sein und dann wären das zahlreiche kurze 4k Zugriffe statt wenige langer, deren Länge nur von der Puffergröße begrenzt wird.

Soweit ich das verstanden habe, wird der SSD mit dem TRIM befehl mitgeteilt, welche Dateien bzw. blöcke "frei" geworden sind. Folglich löscht die SSD dank dieser Info nun die entsprechenden Zellen wodruch sie wieder schneller beschrieben werden können.

Vergiss nicht, man kann NAND zwar pageweise Lesen und Beschreiben, aber nur blockweise löschen. Eine Page ist üblicherweise 4k, 8k und teils schon 16k groß, ein Block umfasst dagegen 256 oder 512 Pages! Wird nur eine Page getrimmt und die anderen 511 sind voller gültiger Daten, so müsste der Controller also im schlimmsten Fall 511 Pages kopieren um die eine, getrimmte dann wirklich löschen zu können. Ein FW Programmierer der sowas wirklich so implementiert gehört erschlagen

Deshalb wird da nur die Verknüpfung des LBA mit der Flashadresse aufgehoben und dann irgendwann der Block gelöscht. Die Aufhebung der Verknüpfung von LBA und Flashadresse bewirkt ja schon, dass ein Zugriff auf die Daten über das normale SATA Interface nicht mehr möglich ist. Wenn natürlich sehr viele oder alle Pages eines Block gerade getrimmt wurden, wird das Löschen vermutlich sehr zeitnah passieren, außer beim Sandforce, denn der löscht ja immer nur direkt vor dem Schreibvorgang, weil das angeblich die Lebensdauer erhöhen soll. Deshalb bringt TRIM bei dem auch wenig und führt eben nicht zu einer Schreibrate wie im Neuzustand, wie es eigentlich gedacht ist.

Umgekehrt zeigt das Verhalten der Sandforce SSDs aber auch gut, dass die FW Programmierer dort eben nicht sofort nach dem TRIM löschen, denn sonst wäre die Schreibrate einer getrimmten SF-SSD so hoch wie die einer mit Secure Erease gelöschten.

 

[frankpr]

Und wie lange soll das dann anhalten? Theoretisch sollte die gewonnene Performance ja wieder verpufft sein, wenn alle Zellen mindestens einmal neu beschrieben wurden. Somit dürfte man das ganze alle paar Wochen machen.

Hängt von Nutzung und Füllstand der SSD ab. Bei meinem RevoDrive mache ich das etwa alle 6 Monate. Also eben davon, wie lange es dauert, bis alle Zellen 1x beschrieben wurden. Und das wiederum dürfte bei einer SSD als Bootlaufwerk schneller gehen als bei einer, auf der nur Programme installiert sind. Zweiteres dürfte vor Allem bei Usern wie HiSN und mir der Fall sein, die komplett HDD-freie Rechner betreiben. Da hält der Effekt auf den reinen "Programmlaufwerken" natürlich schon eine Weile an.
Und es lohnt sich auf jeden Fall, da bei Sandforce SSDs die Schreibrate drastisch einbrechen kann, so daß man es auch im Alltagsbetrieb merkt.
Das erstellen eines Images, Secure Erase mittels OCZ Toolbox und Restore des Images dauert beim Revo Drive 3 X2 insgesamt gut 10 Minuten, da ich auch auf eine SSD sichere, von daher hält sich der Aufwand stark in Grenzen und stellt keinen Grund dar, es nicht zu machen.

Der Unterschied hängt von der Implementierung in der FW ab, denn Secure Erase ist ein SATA Kommando. Es sollte so sein, dass bei Enhanced Secure alle Daten genullt werden und bei Enhanced Secure Erase alle mit einem Muster überschrieben werden, welches der Hersteller vorgibt. Letzteres macht für SSD aber nun wirklich keinen Sinn, aber was konkret passiert, hängt wie schon gesagt von der Implementierung in der FW ab.

Mag so sein. Die PartedMagic Version, die ich nutze, suggeriert halt, daß nur bei Enhanced Secure Erase die interne Firmware Routine verwendet wird. Letztendlich ist es auch Wurscht, wie es heißt, Hauptsache, es bringt den gewünschten Effekt.

Daher rate ich von einem Secure Erase / Intel Toolbox ab: http://www.hardwareluxx.de/community/f227/intel-x25-m-g2-postville-im-panikmodus-834145.html

Dieses ganz spezifische Problem hat allerdings wenig bis nichts mit dem Thema dieses Threads zu tun.

Ohne jetzt genau zu lesen was du schreibst: willst du mir widersprechen?

Selbstverständlich.

Denk mal drüber nach welchen Aufwand es bedeutet und was es in der Praxis bringt.

Geringer Aufwand, der viel bringt. Und ich schreibe hier nicht, wie andere User, vom Hörensagen, sondern aus eigener Erfahrung. Den Rest Deines Beitrags solltest Du selbst verinnerlichen. Schönen Tag noch.

 

[0815-TYP]

Dieses ganz spezifische Problem hat allerdings wenig bis nichts mit dem Thema dieses Threads zu tun.

Der TE schrieb in Beitrag 1:

Mit Intel SSD Tool da müsste ich ja eine zweite Platte haben mit System damit ich meine SSD die ich löschen will an einem anderen Port anstecken kann. Oder mit Parted Magic von CD aus. Ist das dann auch das gleiche Programm mit dem Ergebnis wie bei Secure Erase?

Da auch die Intel X25-M G2 im Luxx durch die Intel Toolbox geschrottet wurde,hat das sogar sehr viel damit zu tun.

Und im Luxx (der selbe Thread) schrieb auch jemand:

habe genauso meine SSD geschrottet, der Hersteller hat sich geweigert diese zu tauschen. Ich konnts bis her nicht unlocken, auch nicht mit den Master PWs von Secure Erase. Liegt jetzt einfach da als Deko :/. War aber eine andere SSD.

Von daher das ganze rumerase lassen,wenn es nicht unbedingt sein muß.

 

[SheldonCooper]

Den Rest Deines Beitrags solltest Du selbst verinnerlichen. Schönen Tag noch.

DU solltest den Rest meines Beitrags verinnerlichen: "Wenn du dann immer noch der Meinung bist, es wäre sinnvoll, dann lass es dir ausführlich von jemand erklären, der es verstanden hat."

 

[Holt]

da bei Sandforce SSDs die Schreibrate drastisch einbrechen kann, so daß man es auch im Alltagsbetrieb merkt.

Könnte bei den Revos aber auch besonders dramatisch sein, weil die vermutlich nicht getrimmt werden. Zwar hat OCZ behauptet, dass die Revo3 getrimmt werden können, aber unter Win7 wird eigentlich kein TRIM Befehl an SAS bzw. RAID Controller geschickt. Kannst Du mal helfen das zu klären? Ob TRIM wirklich funktioniert, kann man mit dem TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten.

 

[frankpr]

Nö, TRIM läuft leider nicht, zumindest nicht automatisch durch Windows. Unterstützt der einzige Treiber, den OCZ jemals herausgebracht hat, nicht. Was geht, ist der manuelle Anstoß mittels des SSD Tools aus dem Crucial Forum, das ich vor langer Zeit mal hier gepostet hatte und auch so lange für meine 2,5" SSDs genommen hatte, wie Intels RSTe Treiber kein TRIM unterstützt hat.
Überprüft habe ich das mit Harddisk Sentinel, der kann den TRIM Status auch zuverlässig auslesen und läuft bei mir als Dienst.
Der Einbruch der Schreibrate kann, z.B. in Photoshop, tatsächlich beim RevoDrive sehr drastisch sein, dann spürt man ihn auch, da PS ja selbst mit viiieeel RAM exzessiv auf das Arbeitsvolume schreibt. Oder noch besser, in Lightroom Ordner mit sehr vielen Photos synchronisieren, wenn der Katalog und die Thumbnails aktuialisiert werden. Gaaanz großes Kino, der Unterschied (aber immer noch schneller als mit HDD ).
Bei meiner Phoenix Pro merkt man es auch, aber nicht so stark.

Da auch die Intel X25-M G2 im Luxx durch die Intel Toolbox geschrottet wurde,hat das sogar sehr viel damit zu tun.

Nein, das war ein spezielles Problem, Postville SSD mit fehlerhafter Tool Version, das hat zum Laufwerkslock geführt. Der TE hat aber keine Postville, sondern eine Sandforce basierte 520, von der ist dieses Problem nicht bekannt.

Von daher das ganze rumerase lassen,wenn es nicht unbedingt sein muß.

Bei der 520 bringt es eben einiges, siehe oben.

 

[Holt]

Sandforce SSD taugen eben nicht besonders, wenn in kurzer Zeit viele Daten (nach Kompression) geschrieben werden sollen. Dann ist man schnell im Recovery Modus und die Schreibrate geht in den Keller. Dafür hätte ich wirklich eine andere SSD gewählt!

 

[etheReal]

Von daher das ganze rumerase lassen,wenn es nicht unbedingt sein muß.

Also im Prinzip ist Secure Erase nur ein SATA-Command, der dem Controller sagt, dass er jetzt alle Zellen löschen soll.
Eine gute SSD sollte so gemacht sein, dass sie diesen Befehl richtig ausführt, und innerhalb von 20-30 Sekunden alle Zellen sicher löscht, sodass auch als Nebeneffekt die bestmögliche, volle Schreibleistung wiederhergestellt ist.

Wenn eine SSD durch Ausführen von Secure Erase kaputt geht, dann läuft eigentlich bei dem Controller der SSD etwas massiv falsch - auf solche SSDs würde ich in Zukunft lieber verzichten.

Ich habe jedenfalls schon öfters ganz verschiedene SSDs mit Partedmagic Secure Erased, und das ging jedes Mal ohne Probleme und sehr schnell - das sollte der Normalfall sein.

*Edit: dieser folgende Absatz bezieht sich nicht mehr auf das Zitat von 0815-TYP, sondern auf die Diskussion von anderen Teilnehmern auf der ersten Seite!*
Es bringt aber -außer dem sicheren Löschen- nicht besonders viel, natürlich wird nicht die Lebensdauer der Zellen wiederhergestellt - um die Zellen wieder wie neu zu machen, muss man die SSD zu einem Schamanen bringen, der sie beräuchert und betanzt
Natürlich nicht!
Ich frage mich, wie man auf die Idee kommen kann, dass ein Secure Erase die Zellen wieder neu machen soll?
Werkszustand heißt nur, dass alle Zellen leer sind, die Abnutzung geht selbstverständlich nicht weg!

 

[0815-TYP]

Ich frage mich, wie man auf die Idee kommen kann, dass ein Secure Erase die Zellen wieder neu machen soll?
Werkszustand heißt nur, dass alle Zellen leer sind, die Abnutzung geht selbstverständlich nicht weg!

Wo hab ich das denn behauptet?

Kommt da noch ne Antwort zu dieser Unterstellung?

Edit:

Ok,danke etheReal für die Richtigstellung.

 

[Holt]

Wenn eine SSD durch Ausführen von Secure Erase kaputt geht, dann läuft eigentlich bei dem Controller der SSD etwas massiv falsch - auf solche SSDs würde ich in Zukunft lieber verzichten.

Das stimmt, aber das Problem ist wohl eher das Setzen des Passworts, was für Seurce Erease vorgeschrieben ist, denn sonst könnte jedes Programm mal eben den Befehl abschicken, was ein gefundenes Fresse für Viren und Malware wäre. Da gab es aber bei einigen SSD Bugs.

 

[Mr.joker]

Hallo,

mal ne Frage aus der Praxis ... ich hab mir das hier zwar alles durchgelesen (ist ja eine Menge Kompetenz hier im thread versammelt! ), aber so 100% verstanden habe ich es wohl doch noch nicht (sonst müsste ich nicht mehr fragen!).

Ich hab eine Sandisk Exreme 120 GB. Diese habe ich soz. zweigeteilt, 70 GB NTFS für Windows Vista, der Rest ist schon mal in ext4 formatiert (erweiterte Partition, mit drei logischen), da soll mal Linux drauf.
Vista kann ja noch kein Trim, u.a. deshalb habe ich zur Sandisk (mit Sandforce Controller) gegfriffen, weil ich gelesen habe, dass das dann günstig wäre, wegen der GC.

Konkret ist mir jetzt folgendes passiert: Ich hab ein an sich sauberes (Vista-)Image mit Clonezilla auf die mit Gparted bereits formatierte/partitionierte SSD gespielt. In Kurzform: Hab's aber nicht zum Laufen gekriegt. Nach langem Hin und Her (Versuch von Mbr-Fix usw. habe ich mir dann gedacht, was soll's, ich hab's ja und das zweite Image genommen, dass ich mir parallel noch mit Acronis True Image gesichert hatte. Das hat dann geklappt!
Dann wollte ich später eine andere Partition von einer HDD defragmentieren mit JKDefrag und dabei ist mir was Dummes passiert, und zwar habe ich das Häckchen bei "C" übersehen (und bin dann weggegangen vom PC), so wurde das frisch aufgespielte Image (dessen Dateien vor Imageerstellung und Aufspielen noch schön nach Erstelldatum defragmentiert wurden) noch mal neu defragmentiert und zwar diesmal nach "Name"!
Mein Vista belegt derzeit knapp 35 GB der 70 GB NTFS Partition. Vor allem bei Vista handelt es sich eigentlich um eine reine System- und Programmpartition, die Daten liegen auf einer HDD. Bei Linux kommt halt noch eine /home Partition dazu und die Swap (ich will aber die Einstellungen so setzen, dass möglichst wenig "geswappt" wird, und auf die /home werden auch nur eher wenige Downloads kommen.

Jetzt zu meiner 1. Frage: Hab ich's jetzt vielleicht schon vermasselt? Muss ich jetzt vielleicht schon mit den hier erwähnten "Einbrüchen" rechnen?
Erfahrungswerte mit der Geschwindigkeit einer SSD habe ich halt noch keine. "Gefühlt" würde ich sagen, war ich etwas enttäuscht, da mein Vista immer noch ca. eine Minute braucht, bis es mit ein paar Zusatzprogrammen vollständig gestartet ist. Könnte aber auch daran liegen, dass mein SATA-Controller auf dem Mainboad sowieso nur SATA II unterstützt!

Und weiterführend frage ich mich, wie ich das in Zukunft am besten handeln soll, von wegen Secure Erase ...
Denn eigentlich würde ich am liebsten jetzt noch ein wenig mit den Images herumspielen, das noch mal mit Clonezilla versuchen, um den Fehler zu ergründen. Und, wenn ich mir erst mal Linux parallel installiert habe (was ja aber Trim können soll?), werde ich dort vor allem am Anfang eh hin und wieder mal ein Image zurückspielen, weil ich mir die Installation (beim Üben mit Linux!) zerschossen habe.
Also, 2. Frage: Gibt es eine "Faustregel", nach wieviel Mal Image Zurückspielen man ein Secure Erase machen sollte? Bzw. inwieweit ist das davon abhängig, ob das BS Trim kann oder nicht?

 

[powerfx]

TRIM sollte ja die gelöschten Daten "aufräumen" und entsprechende Zellen frei geben. Falls das OS TRIM nicht unterstützt, gibt's immer noch die GC. Und außerdem gibt es oft Herstellertools (bei SanDisk weiß ich nicht - vielleicht gibt es aber was Generisches für SandForce), die eine Art manuelles TRIM haben um die GC anzustoßen. Du kannst ja mal danach schauen.

Je nach Kernel und Dateisystem bei Linux wird TRIM unterstützt oder auch nicht, aber vor allem ist es nicht bei jeder Distribution auch wirklich aktiv. Hinweise und ein Testverfahren dazu gibt es hier.

 

[Holt]

Jetzt zu meiner 1. Frage: Hab ich's jetzt vielleicht schon vermasselt? Muss ich jetzt vielleicht schon mit den hier erwähnten "Einbrüchen" rechnen?

Die wird schon bald in den Normalzustand gehen, denn durch das Defragmentieren wurden nun wohl schon doppelt so viele geschrieben wie vorhanden sind. Aber das passiert ja sowieso früher oder später bei den Sandforce immer, weshalb das ja auch der Normalzustand ist und die volle Geschwindigkeit eben im Neuzustand erreicht wird. Weitere Einbrüche, wenn der Controller in den Recoveryzustand geht, kannst Du nur vermeiden, wenn Du eben verhinderst zu viele Daten am Stück zu schreiben, davon erholt er sich aber auch nach einige Zeit im Idle wieder.

Erfahrungswerte mit der Geschwindigkeit einer SSD habe ich halt noch keine. "Gefühlt" würde ich sagen, war ich etwas enttäuscht, da mein Vista immer noch ca. eine Minute braucht, bis es mit ein paar Zusatzprogrammen vollständig gestartet ist. Könnte aber auch daran liegen, dass mein SATA-Controller auf dem Mainboad sowieso nur SATA II unterstützt!

Die Bootzeit hängt weniger von der Performance der SSD als viel mehr von der Zeit für die Initialisierung der HW ab. Wenn Du aber Zweifel an der Perfomance hast, benche mal mit dem AS-SSD Benchmark und poste den Screenshot davon (bitte nur von AS-SSD) im passenden [Sammelthread] Sind die Werte meiner SSD in Ordnung? (Teil VI) .

Und weiterführend frage ich mich, wie ich das in Zukunft am besten handeln soll, von wegen Secure Erase ...

Gar nicht, vergiss das einfach! Die Arbeit lohnt sich nicht, denn nach einiger Zeit ist die Schreibrate wieder runter, weil die SSD im Normalzustand ist.

frankpr schreibt ja viel zu viel Daten, denn Videos sind ja nicht mehr komprimierbar und wenn das noch jeweils viel Daten am Stück sind, kommt er regelmäßig in den Recoverymodus, den erst nach dem Secure Erease, solange die SSD im Neuzustand ist, noch nicht gibt. Der kommt erst im Normalzustand, weil der SF immer nur so viel Kapazität aufräumt, wie ab Werk an Overprovisioning vorhanden ist und niemals mehr. Andere Controller räumen im Idle die ganze (aus ihrer Sicht) freie Kapazität auf und löschen die Blöcke auch gleich. Der Sandforce löscht immer erst direkt beim Schreiben, weshalb die Schreibrate eben geringer wird und wenn der aufgeräumte Bereich voll ist, muss vorher auch noch aufgeräumt werden. Das senkt dann die Schreibrate weiter, weil ja die als nächstes zu löschenden Blöcke ausgewählt werden müssen und die noch gültigen Daten in den Blöcken noch in andere Pages kopiert werden müssen, womit dann obendrein noch weniger Platz in den vorher gelöschten Blöcken für die neu zu schreibenden Daten bleibt. Damit ist klar, dass die Schreibrate eben in die Knie geht.

wenn ich mir erst mal Linux parallel installiert habe (was ja aber Trim können soll?), werde ich dort vor allem am Anfang eh hin und wieder mal ein Image zurückspielen, weil ich mir die Installation (beim Üben mit Linux!) zerschossen habe.

Linux trimmt nur, wenn das beim Mounten entsprechend angegeben ist und natürlich nur für die Linux Partition.

Also, 2. Frage: Gibt es eine "Faustregel", nach wieviel Mal Image Zurückspielen man ein Secure Erase machen sollte? Bzw. inwieweit ist das davon abhängig, ob das BS Trim kann oder nicht?

Lass das mit dem Secure Erase am besten ganz bleiben. Mit TRIM hat das auch wenig zu tun, der Unterschied zwischen TRIM oder nicht TRIM ist beim Sandforce erst im Recoverymodus zu spüren, weil er dann eben ein paar Pages weniger kopieren muss, eben die die getrimmt wurden. Das ist bei anderen Controllern anders, da kann man die getrimmt Kapazität dann auch wirklich hinterher wieder am Stück mit der vollen Schreibgeschwindigkeit wieder beschreiben. Bei Sandforce geht das, wie gesagt, sowieso nie, denn der räumt eben immer nur eine feste Kapazität auf, weshalb das Fehlen von TRIM bei dem eben weniger Unterschied macht, aber eben nicht weil der besser wäre sondern weil der sowieso nur einmal im Neuzustand bzw. nach dem SE in der Lage ist die volle Kapazität mit der vollen Schreibgeschwindigkeit zu beschreiben und dann nicht mehr. Der Sandforce nutzt also die Vorteile von TRIM nicht so wie andere Controller und daher bemerkt man den Nachteil nicht so, wenn TRIM fehlt.

TRIM sollte ja die gelöschten Daten "aufräumen" und entsprechende Zellen frei geben.

TRIM ist ein SATA Kommando und sagt dem Controller nur, welche Daten er als ungültig betrachten und damit löschen können, weil die Datei gelöscht wurde zu der diese Daten gehören. Das setzt eben jeder Controller anders um, die Sandforce wie oben beschrieben. Bei den meisten anderen SSDs kommt es von der Performance her auf das gleiche raus, ob man ein Secure Erease macht oder alle LBAs timmt, aber beim Sandforce ist das eben nicht so und nur das Secure Erease bringt die volle Performance zurück.

Falls das OS TRIM nicht unterstützt, gibt's immer noch die GC.

Das ist keine Alternative, die GC übernimmt auch das Löschen der getrimmten Daten, nur ohne TRIM kann die GC halt nur Daten löschen, die zu einer LBA gehören, die wieder überschrieben wurde.

Und außerdem gibt es oft Herstellertools (bei SanDisk weiß ich nicht - vielleicht gibt es aber was Generisches für SandForce), die eine Art manuelles TRIM haben um die GC anzustoßen. Du kannst ja mal danach schauen.

Diese Tools stoßen nicht die GC an, die können aber teilweise die freien LBA ermitteln und dann TRIM Befehle dafür schicken. Das geht auch mit Tool wie dem Free Space Trimmer oder dem AS FreeSpaceCleaner.

Ergänzung (17. August 2013)

Ob das TRIM damit wirklich funktioniert hat, kann man mit dem TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen lässt man halt das TRIM Tool laufen.