Solid State Drive (SSD) (Part 8)

[A_H]

Zitat:
>Die SSD löscht die Zellen anstatt sie mit Nullen zu beschreiben.<

Ich habe das bisher so verstanden, dass die SSD zum Löschen/Trimmen/Schreibvorbereiten die Zelle der SSD auf einen bestimmten Widerstandswert zieht, der dem Zahlenwert 0 (SLC) bzw. 00 (MLC) entspricht.

In der Situation bedauere ich, dass ich nur eine SSD bzw ein Windows 7 auf dem PC habe. Wenn sich sonst kein Versuchskaninchen findet, werde ich auf der SSD eine Testpartition anlegen.

Wenn ich mich recht erinnere, zeigt der "Datenträgerbetrachter" von Acronis auf den Sektoren, die ich für getrimmt halte, lauter Nullen an.

 

[Wolfsrabe]

So langsam verstehe ich auch, warum es für ein älteres Betriebssystem nicht einfach ist, mit einer SSD "gut" umzugehen - eben weil es immernoch "glaubt", es laufe auf einer HDD.

Was TRIM unter Windows 7 betrifft, habe ich noch Verständnisprobleme.
Der TRIM-Befehl wird also losgeschickt, wenn der Papierkorb geleert wird, oder - wenn jemand den Papierkorb gar nicht nutzt - direkt löscht.
Was ist aber mit solchen Löschvorgängen, die gar nicht oder nur indirekt vom User ausgehen? Zum Beispiel beim Deinstallieren von Programmen, das Löschen der Chronik unter Firefox, beim Ausführen von CCleaner und und und? Kapiert Windows 7 hier auch, daß es sich um Löschvorgänge handelt und schickt den TRIM befehl los?

 

[A_H]

ursprünglich gings beim Fullformat doch ums klären ob der datenträger defekte sektoren hat. Dazu müsste man aber die Sektoren lesen, schreiben egal. Mit testen auf defekte Sektoren hat trim auch nichts zu tun.

Ja, das scheint bei der SSD obsoltet zu sein. Das macht die wohl selbst beim Schreiben - vielleicht, wahrscheinlich...

 

[pajaa]

Ja, das scheint bei der SSD obsoltet zu sein. Das macht die wohl selbst beim Schreiben - vielleicht, wahrscheinlich...

Das muss sie selbst machen, da es für das OS nicht transparent ist, wo und wie geschrieben wird. Ist eine Zelle erschöpft und kann nur noch gelesen werden, müssen die Reservezellen genutzt werden. Dies sollte dann allerdings in den Smartwerten ersichtlich sein.

Die SSD löscht die Zellen anstatt sie mit Nullen zu beschreiben.

Die Speicherzelle kennt nur 2 Zustände: 0 und 1, keine Spannung oder Spannung. Im Endeffekt geht es darum, die Zellen als leer zu MARKIEREN, damit diese nicht zuerst ausgelesen werden muss, um dies festzustellen.
Im Grunde reicht es, die Zellen in der Volumebitmap als leer zu markieren. Genau das macht übrigens TRIM

 

[A_H]

Hier steht auch etwas dazu:
http://de.wikipedia.org/wiki/NAND-Flash
Da steht etwas von Spannungsniveau. Naja, Spannung und Widerstand hängen zusammen, an einem Widerstand gibt es einen Spannungsabfall, erinnert mich an einen AD- oder DA-Wandler.

 

[pajaa]

Du hast natürlich recht: Es sind Spannungsniveaus, wobei auch hier ein oder 2 Niveaus als 0 und 1 oder 2 als 1 definiert sind.

 

[A_H]

http://de.wikipedia.org/wiki/MLC-Speicherzelle
Da ist unten eine Tabelle, da wird von Widerstand geredet.
Ich würde grob und ungenau sagen, ein Widerstand wird mittels einer Spannung ausgelesen.

Edit: Und die resultierende Spannung repräsentiert gegenüber dem Controller die Bitbelegung.

 

[Powermikey]

Was TRIM unter Windows 7 betrifft, habe ich noch Verständnisprobleme.
Der TRIM-Befehl wird also losgeschickt, wenn der Papierkorb geleert wird, oder - wenn jemand den Papierkorb gar nicht nutzt - direkt löscht.
Was ist aber mit solchen Löschvorgängen, die gar nicht oder nur indirekt vom User ausgehen? Zum Beispiel beim Deinstallieren von Programmen, das Löschen der Chronik unter Firefox, beim Ausführen von CCleaner und und und? Kapiert Windows 7 hier auch, daß es sich um Löschvorgänge handelt und schickt den TRIM befehl los?

Ja, das tut es. Bei jedem Löschvorgang, egal durch welche Software ausgelöst, wird der TRIM-Befehl durchgereicht. Unter XP konnte ich mit HdTach immer schön sehen, wenn ich z.B. mit Nero Vision eine DVD erstellt habe, wo die Gigabyte großen Temporärdateien liegen bzw. lagen. Nach leeren des Temp-Orners waren die "langsamen Zonen" in HDTach immer noch sichtbar - erst wiper beseitigte diese.

Unter Windows 7 ist nach Beendigung eines solchen Programms nachher nichts mehr zu sehen, die SSD ist nach noch genauso schnell wie vorher - als hätte man "gewipert".

Mit Papierkorb hat TRIM nichts zu tun.

Grüße

 

[Morpog]

Die Speicherzelle kennt nur 2 Zustände: 0 und 1, keine Spannung oder Spannung. Im Endeffekt geht es darum, die Zellen als leer zu MARKIEREN, damit diese nicht zuerst ausgelesen werden muss, um dies festzustellen.
Im Grunde reicht es, die Zellen in der Volumebitmap als leer zu markieren. Genau das macht übrigens TRIM

Das ist mir klar. Ich wollte damit ausdrücken dass eben das Betriebssystem nicht feststellen kann ob eine Zelle 0 oder 1 hat, sondern darauf vertrauen muss was der SSD Controller als Wert zurückliefert.

Hatte mich da leider ein bisschen doof ausgedrückt.

Sprich ein getrimmter Bereich und ein langsam formatierter Bereich werden in der NTFS $Bitmap beide als leer angesehen. Auf SSD Controllerebene aber eben nicht.

 

[pinki]

doch, hat es, unter anderem wird auch durch leeren des papierkorbs ein trim befehl an die SSD gesand.
Ganuso wenn man eine datei direkt löscht oder ein programm dies tut, kommt immer aufs selbe raus denn die programme die du meinst tun ja auch nichts anderes als den lösch befehl zu geben.

 

[pajaa]

Sprich ein getrimmter Bereich und ein langsam formatierter Bereich werden in der NTFS $Bitmap beide als leer angesehen. Auf SSD Controllerebene aber eben nicht.

Richtig. Ich wollte es nur nochmal verdeutlichen

doch, hat es, unter anderem wird auch durch leeren des papierkorbs ein trim befehl an die SSD gesand.
Ganuso wenn man eine datei direkt löscht oder ein programm dies tut, kommt immer aufs selbe raus denn die programme die du meinst tun ja auch nichts anderes als den lösch befehl zu geben.

Der Vollständigkeit sei hier noch erwähnt, daß der TRIM-Befehl nur gesendet wird, wenn das OS das auch kann. Nicht daß hier noch irgendein Neuling mitliest und denkt, daß immer geTRIMt wird.

 

[Powermikey]

doch, hat es, unter anderem wird auch durch leeren des papierkorbs ein trim befehl an die SSD gesand.
Ganuso wenn man eine datei direkt löscht oder ein programm dies tut, kommt immer aufs selbe raus denn die programme die du meinst tun ja auch nichts anderes als den lösch befehl zu geben.

Das meinte ich, habe mich vielleicht missverständlich augedrückt - das leeren des Mülleimers ist nicht anderes als jeder andere x-beliebige Löschvorgang des Betriebssystems, egal von welchem Programm intitiiert. Sogar beim nicht empfohlenen defragmentieren der SSD scheint Win7 zu trimmen.

Grüße

 

[Morpog]

ursprünglich gings beim Fullformat doch ums klären ob der datenträger defekte sektoren hat. Dazu müsste man aber die Sektoren lesen, schreiben egal. Mit testen auf defekte Sektoren hat trim auch nichts zu tun.

Seit Vista und 7 wird aber zusätzlich noch mit Nullen beschrieben.

 

[A_H]

Sprich ein getrimmter Bereich und ein langsam formatierter Bereich werden in der NTFS $Bitmap beide als leer angesehen. Auf SSD Controllerebene aber eben nicht.

Genau, denke ich. Das System wird also ohne manuelles TRIM oder ohne einen kompletten Eraseblock (den ich in der Größe von 64 oder 128KByte vermute) zu schreiben und wieder zu löschen für die langsam formatierten Bereiche niemals nachträglich ein TRIM schicken. Wenn dann in so einem Eraseblock eine kleinere Datei geschrieben und gelöscht wird, muss die langsam formatierte SSD denken, halt da ist noch was, ich muss den Kram stehen lassen. Wenn dann Windows den ganzen Block und mehr beschreiben will, der ja laut seiner Bitmap frei ist, dann macht die SSD das artig und zähneknirschend, es dauert aber länger.

Entsprechend würde es beim Restore eines Backups aussehen, falls Acronis vorher kein TRIM rauskitzelt. Die $Bitmap entspricht dem neuen Zustand, aber die SSD sieht die Summe (Vereinigungsmenge) von altem und neuem Dateisystem - tückisch.

(Es geht hier immer um Windows 7 mit Autotrim.)

 

[Cippoli]

Seit Vista und 7 wird aber zusätzlich noch mit Nullen beschrieben.

Was übrigens auch alle Tools der Festplattenhersteller können/machen, damit die HDD wieder in den Werkszustand versetzt wird.

Hier müsste Windows die SSD erkennen und sowas erst gar nicht zulassen.

 

[pajaa]

Wenn dann in so einem Eraseblock eine kleinere Datei geschrieben und gelöscht wird, muss die langsam formatierte SSD denken, halt da ist noch was, ich muss den Kram stehen lassen. Wenn dann Windows den ganzen Block und mehr beschreiben will, der ja laut seiner Bitmap frei ist, dann macht die SSD das artig und zähneknirschend, es dauert aber länger.

Nein, da der Controller die Daten dahin schreibt, wo er das für richtig hält. Es ist dem OS nicht möglich, der SSD vorzugeben, was sie wohin schreiben soll. Hier hat das mal jemand sehr treffend beschrieben: das OS schickt eine Datei mit Adresse an die SSD, der Controller schreibt die Adresse auf und wirft die Datei dann in einen Block, der verfügbar ist.

Sind für den Controller keine als leer markieren Blöcke mehr da, muss er den Inhalt erst auslesen, dann endsprechend die neue Datei hinzufügen und wieder speichern. Das dauert.

 

[Powermikey]

Seit Vista und 7 wird aber zusätzlich noch mit Nullen beschrieben.

Das mit den Nullen verwirrt mich, laut OCZ-Forum müsste der freie Speicher mit FF überschrieben werden, um diesen für die SSD leer erscheinen zu lassen. Sonst würde der Freespacecleaner mit Option "FF" ja nicht fast so gut funktionieren wie wiper...habs selbst schon vor Monaten getestet...damals noch mit dem trimmlosen XP...

Grüße

 

[A_H]

Nein, da der Controller die Daten dahin schreibt, wo er das für richtig hält.

Jein. Das ist ganz egal, ob der Controller nochmals mapped/umlagert, oder wie man das nennen will. Da geht es um eine Schicht ganz unten im ISO/OSI-Modell. Logisch muss das Betriebssystem bzw. der Programmierer schon sagen können, auf welcher Adresse im Speicher ein bestimmter Datensatz landen soll.

Ist hier aber auch nicht relevant. Angenommen unser jetziges Denkmodell bezüglich langsamer Formatierung ist richtig, dann müsste der Controller bei einem neu installierten System immer denken, dass die gesamte SSD voll ist. Wenn dann eine kleine Datei kommt, geht der Controller davon aus, dass er einen bereits belegten Bereich überschreiben soll und tut das - langsam. Und mit einer anderen kleinen Datei passiert das an einer anderen Stelle usw. Wenn dann TRIM-Befehle für die kleinen Dateien kommen, registriert der Controller das, sagt aber Mist, keine ganzen Eraseblöcke frei. Später wird wieder langsam über die für Windows gelöscht aussehenden Bereiche geschrieben. So könnte der Krampf ewig weiter gehen. Erst wenn ein gesamter Eraseblock mal zufällig frei (von Windows beschrieben und gelöscht) ist, kann der Controller den Block "grundieren" und die Not hat an einer Stelle der SSD ein Ende.

So jedenfalls könnte ich mir Schreibraten von 66,3MB/s erklären.

---------- Beitrag hinzugefügt um 18:56 ---------- Vorheriger Beitrag war um 18:52 ----------

Das mit den Nullen verwirrt mich, laut OCZ-Forum müsste der freie Speicher mit FF überschrieben werden, um diesen für die SSD leer erscheinen zu lassen. Sonst würde der Freespacecleaner mit Option "FF" ja nicht fast so gut funktionieren wie wiper...habs selbst schon vor Monaten getestet...damals noch mit dem trimmlosen XP...

Grüße

Jo, das mit FF ist auch noch so ein Thema, das dachte ich auch.
Dieses Teil von Acronis zeigt aber hex 00 an - wenn ich das richtig verstehe.

 

[Morpog]

.......dann müsste der Controller bei einem neu installierten System immer denken, dass die gesamte SSD voll ist.

Warum das? Ich kenne eigentlich niemanden der langsam formatiert. Ausserdem würde ein Lauf mit freespacecleaner das Problem beheben. Oder noch einfacher mit dem wiper tool.

 

[Orbmu2k]

Entscheidend ist was in der Filetable steht. Also Datei x.y an position P mit länge L. Damit ist für das Filesystem alles klar. Wird eine Datei gelöscht wird der entsprechende Eintrag aus der Tabelle entfernt. Damit ist der Bereich für das Dateisystem wieder neu beschreibbar. Nur die SSD/Controller hat davon nix mitbekommen und die Daten stehen immernoch wie gehabt an ihrer Position, das ist bei ner HDD nich anders. Allerdings musst die SSD einen Block erst löschen bevor man ihn neu beschreiben kann. Das macht sie in dem Fall dann beim nächsten beschreiben automatisch ... oder wenn getrimmt wurde weiss sie schon in ihrer Eraseblock Map das der Block schon zurückgesetzt wurde und sie direkt neu schreiben kann ohne zu löschen. Das funktioniert aber nur so lange wie auch der komplette Block betroffen ist. Ein halb gefüllter Block kann nicht getrimmt werden und wird beim schreiben von zusätzlichen Daten immer vorher gelesen -> cache -> aktualisiert -> block gelöscht -> neu geschrieben.

Wie der SSD Controller die Adressierung macht kann ich nur Spekulieren. Ich denke er mach keine Sektor Map sondern eine Erase Block Map. Also Welcher Speicherbereich welchem Erase Block zugeordnet ist. Das wird immer zusammenhängender Physikalischer Bereich also Sektor X bis Sektor Y sein.

Somit ist dem Controller auch schnuppe was wo liegt ... er muss nur wissen wo er welchen Sektorbereich abgelegt hat.

Beim Formatieren werden alle Tabellen Partitionstabelle / Dateitabelle entfernt und ggf Sektorweise mit 0en beschrieben. Somit schreib der SSD Controller in alle seine Blöcke 0en. Das ist der SSD egal. Daten sind Daten.

Erst durch TRIM bekommt die SSD gesagt ... den Block kannst du schonmal zurücksetzen damit er beim nächsten schreiben nicht gelöscht werden muss.

 

[A_H]

Warum das? Ich kenne eigentlich niemanden der langsam formatiert. Ausserdem würde ein Lauf mit freespacecleaner das Problem beheben. Oder noch einfacher mit dem wiper tool.

Klar, keine Frage - nur wissen muss man es. Dann hätte sich aber auch Pinkis Einwand bezüglich Normalformatieren relativiert. Um den ging es doch die ganze Zeit. Ich habe nach schlechten Erfahrungen mit Quickformat immer langsam formatiert, und ich bilde mir ein, damit auch ein Anfangsproblem mit der SSD im letzten September beseitigt zu haben.

 

[Morpog]

Das funktioniert aber nur so lange wie auch der komplette Block betroffen ist. Ein halb gefüllter Block kann nicht getrimmt werden und wird beim schreiben von zusätzlichen Daten immer vorher gelesen -> cache -> aktualisiert -> block gelöscht -> neu geschrieben.

Genau an der Stelle kommt ja das GC Feature ins Spiel und fasst viele teilbelegte Blöcke in weniger vollbelegte Blöcke zusammen.

---------- Beitrag hinzugefügt um 19:31 ---------- Vorheriger Beitrag war um 19:27 ----------

Klar, keine Frage - nur wissen muss man es. Dann hätte sich aber auch Pinkis Einwand bezüglich Normalformatieren relativiert. Um den ging es doch die ganze Zeit.

Es soll SSDs und Betriebssysteme ohne TRIM Feature geben

Ausserdem hat pinki ja recht mit seiner Warnung nicht langsam zu formatieren. Warum soll ich erst langsam formatieren und dann nach OS Installation den freespacecleaner das Dilemma wegräumen lassen? Da gehen ja mal schwupp di wupps fast 2 Zyklen drauf!

 

[pajaa]

Jein. Das ist ganz egal, ob der Controller nochmals mapped/umlagert, oder wie man das nennen will. Da geht es um eine Schicht ganz unten im ISO/OSI-Modell. Logisch muss das Betriebssystem bzw. der Programmierer schon sagen können, auf welcher Adresse im Speicher ein bestimmter Datensatz landen soll.

Wieso? Zumal dieses Vorgehen gegen das Wear-Leveling arbeiten könnte. Das SSD sagt zwar, daß sich die Datei an der Adresse befindet, aber sie liegt halt da, wo der Controller es für richtig hält. Es ist schlicht nicht transparent, welche Daten wo liegen.

Zum Zweiten: Hält der Controller ein SSD für vollbeschrieben, wird immer ein read-modify-write durchgeführt, der nunmal langsamer ist als das alleinige Schreiben. Dazu verweise ich auf die Truecrypt-Problematik, wo das gesamte Laufwerk mit Zufallsdaten vollgeschrieben wird.

 

[Freudenberger]

sagt mal hat jemand von euch die ssd mit hdd erase formatiert? ich habe das problem das ich kein diskettenlaufwerk habe jedoch das progrmam nutzen will. wie bekomme ich z.B. ein usbstick bootable mit dem programm hdd erase? kann mir da jemand helfen?

 

[stw500]

Irgendwer hatte entweder in den hardwareluxx oder im Computerbase forum im Bereich SSDs mal nen Link gepostet für ein CD-Image. Ich habe meines aber damals über google gefunden. Such mal nach hdderase 3.3 und dann vielleicht image oder so...wirste schon finden.

EDIT: War gleich an erster Stelle bei Google...war so einfach, dafür braucht man eigentlich kein Forum...

http://www.markc.me.uk/MarkC/Blog/Entries/2009/8/13_Erasing_an_SSD.html

 

[Kurbel]

wie bekomme ich z.B. ein usbstick bootable

hp usb disk storage format tool + Bootdateien

 

[Techtrancer]

Ab März soweit ich weiss.

cool!

is ja nicht mehr lange

bin ich mal gespannt drauf

 

[AristoChat]

Mtron is no more ...

RIP

 

[Freudenberger]

servus.... ich habe es endlich hinbekommen mit hdd erase jedoch möchste ich jetzt wissen b ich option 1: secure erase oder option 2 enhanced secure erase auswählen soll. was ist besser?

 

[Morpog]

Meinst du nicht dass deine Frage in einem Thread ausgereicht hätte?