Sammelthread / Kaufberatung SSDs

Status
Für weitere Antworten geschlossen.
mumpel schrieb:
Dafür ist die GC verantwortlich.
Ja genau, aber überlege doch mal, wie es das machen soll. Seine Aufgabe ist es für frisch geflashte Bereiche zu sorgen, damit nicht erst beim Schreiben der Daten geflasht werden muß, weil das dann langsam wird. Nun kann es aber nur ganze Cells flashen, so typischerweise 32 bis 128 Pages (typ. 4k). Nach einiger Zeit werden zwangsläufig in der Page Daten liegen, die zu verschiedenen Dateien gehören. Einige davon werden weiterhin benötigt und andere nicht mehr, weil die Datei eben schon gelöscht wurde.
Mit TRIM ist es einfach diese zu kennen, aber ohne TRIM? Wie soll GC da seiner Verantwortung nachkommen können?
Es greift eben einfach zu kurz wenn man sich sagt, dafür ist GC verantwortlich, das macht das schon und deshalb bleibt die Performance immer gleich. Stell Dir einfach mal vor, Du müßtest diese GC selbst schreiben, dann kannst Du auch verstehen, was es leisten kann und was nicht, wann es wichtig ist und wann nicht.
mumpel schrieb:
Überleg doch mal: Es gibt mehrere Szenarien, wo TRIM nicht funktioniert (XP, Vista, OS X, IDE-Modus, RAID, SSD unterstützt gar kein TRIM usw.) - eigentlich gibt es nur ein Szenario wie TRIM funktioniert: Windows 7/Linux ab Kernel v2.6.33 + AHCI-Modus + SSD mit TRIM-Support. Meinst du, deren SSDs sind nach einmaligem Beschreiben (performancetechnisch) im Arsch?
Nein und das habe ich auch niemals behauptet, Probleme treten erst auf, wenn man die SSD einmal komplett voll geschrieben hat, weil dann das GC eben nur noch die Spare Area als freien Platz zur Verfügung hat und wenn man dann mehr Daten schreibt als Spare Area zur Verfügung stand, dann geht die Schreibgeschwindigkeit runter. Denn nachdem dieser freie Bereich voll ist, muß der Controller erst mal sehen, welche Sektoren jetzt eigentlich beschrieben werden / gerade wurden, kann die Cellls mit den Pages in denen die Daten dieser Sektoren leeren (und muß dabei ggf. noch gültige Daten umkopieren) um dann weiterschreiben zu können. Danach kann GC wieder aufräumen und wieder soviel freien Platz zur Verfügung stellen. wie es an Spare Area hat, aber nicht mehr.
Spare Area in diesem Sinne ist nur die vom Hersteller vorgesehene Spare Area sondern auch alle niemals beschriebenen Sektoren der SSD. Stelle Dir eine HDD vor deren Datensekoren beim Formatieren alle mit Nullen gefüllt werden. Alle Sektoren die immer noch mit Nullen gefüllt seid weil sie niemals beschrieben wurden, zählen dann dazu.
mumpel schrieb:
Auf keinen Fall! Ich habe hier bspw. eine Intel x25-m G1 ohne TRIM-Support, im IDE-Modus unter XP als System-Disk seit ~2 Jahren am laufen. Die Performance ist wie im ersten Tag, kein MB/s Unterschied. Und jetzt komm' mir nicht, dass ich die 80 GB noch nicht voll geschrieben habe ;)
War Deine SSD jemals 100% gefüllt, also ohne freie Bytes mehr? Wohl kaum. Es geht nicht um die Datenmenge die in der Zeit geschieben wurde, es geht gewissenmaßen um den Hochwasserpegel.
Wäre dem nicht so, gäbe es nicht Tools wie Secure Erease die SSD Nutzer zum Wiederherstellen der Ausgangsleistung verwenden, weil sie die sonst nicht mehr erreichen. Solche Tools sagen dem Controller ganz einfach: Mach mal alles weg und damit ist die SSD auch für ihn wieder komplett leer. Könnte der Controller bzw. sein GC Algorithmus das irgendwie anders hinbekommen, dann bräuchte man solche Tools nicht bzw. sie hätten keinen Nutzen.
Wenn Deine X25M keinerlei Performanceeinbrüche beim Schreiben zeigt, dann schreibst Du nie mehr als Dein Controller auf Deiner SSD immer an freiem Bereich zur Verfügung stellen kann und dann hat das Fehlen von TRIM nur Auswirkungen auf die Lebensdauer, aber bei denen 50nm NANDs solltest Du die nicht spüren können.
 
@ Holt:
You can only erase groups of pages at a time in a structure called a block (usually 128 or 256 pages). Each cell in NAND can only be erased a finite number of times so you want to avoid erasing as much as possible. The way you get around this is by keeping data in NAND as long as possible until you absolutely have to erase it to make room for new data. SSD controllers have to balance the need to optimize performance with the need to write evenly to all NAND pages. Conventional controllers do this by keeping very large tables that track all data being written to the drive and optimizes writes for performance and reliability. The controller will group small random writes together and attempt to turn them into large sequential writes that are easier to burst across all of the NAND devices. Smart controllers will even attempt to reorganize data while writing in order to keep performance high for future writes. All of this requires the controller to keep track of lots of data, which in turn requires the use of large caches and DRAMs to make accessing that data quick. All of this work is done to ensure that the controller only writes data it absolutely needs to write.

Es geht nicht darum, dass ich (oder du) einen GC-Algorithmus schreiben könnte. Andere intelligente Männer haben das schon für uns getan und es funktioniert genau so. Natürlich gibt es schlechtere und bessere Implementierungen und außerdem muss immer eine Balance zwischen Performance und Lebensdauer des NAND gefunden werden. Das unterscheidet sich von Controller zu Controller. Während bspw. Sandforce da sehr behutsam rangeht (mit dem Effekt, dass die Schreibperformance nach einer Vollbeschreibung dauerhaft um fast 50% einbricht), geht Toshiba aggressiver ran (mit dem Effekt, dass die Performance innerhalb kürzester Zeit komplett wiederhergestellt ist, aber die Lebenszeit des NAND drunter leidet).

TRIM ist letztlich nur ein Befehl, den das OS an die SSD sendet, damit der Controller weiß, dass die Datei/Block gelöscht werden kann. Was die SSD damit dann macht, ist individuell. GC ist der komplette Mechanismus, wie die nicht genutzte Daten gesammelt werden und freie Speicherbereiche gruppiert und freigehalten werden. TRIM spielt in so fern der GC zu, weil der Controller nicht raten muss, welche Dateien gelöscht werden können. Trotzdem tut es der Controller, damit er in Umgebungen ohne TRIM seine Performance wieder herstellen kann.

TRIM hat also mit der Lebensdauer wenig zu tun. Und ob 50, 34 oder 25 nm hat mit TRIM oder GC auch wenig zu tun. Nur in sofern, dass die Löschzyklen mit kleinerer Struktur drastisch sinken und die GC im besten Fall darauf Rücksicht nehmen sollte.
 
mumpel schrieb:
@ Holt:
TRIM ist letztlich nur ein Befehl, den das OS an die SSD sendet, damit der Controller weiß, dass die Datei/Block gelöscht werden kann.
Das habe ich doch immer geschrieben: TRIM ist ein Befehl der dem Controllerder SSD die Sektoren mitteilt, auf denen die Daten der gelöschten Datei lagen. Bei Lesen der Datei teilt das OS dem Controller diese Sektoren ja auch mit, allerdings mit der Aufforderungen die Daten darin zu lesen und zu übertragen.
mumpel schrieb:
Was die SSD damit dann macht, ist individuell.
Ja und nein, letztlich muß die SSD spätestens wenn keine frischer oder gelöschter Speicher mehr zur Verfügung steht und Daten geschrrieben werden müssen, einen Lock auswählen, die noch gültigen Daten darin woandershin kopieren und diesen dann löschen.
Wie und wann ausgewählt wird ist individuell, was gemacht wird aber für alle gleich.
mumpel schrieb:
GC ist der komplette Mechanismus, wie die nicht genutzte Daten gesammelt werden und freie Speicherbereiche gruppiert und freigehalten werden.
Richtig.
mumpel schrieb:
TRIM spielt in so fern der GC zu, weil der Controller nicht raten muss, welche Dateien gelöscht werden können.
FALSCH! Genau in zweiten Halbsatz ist dein Denkfehler: Der Controller darf und kann nicht raten, welche Daten er löschen kann!! Stell Dir vor wie schnell er sich beim Raten irren würde und dann wärst Du schnell dabei Dein Backup rauszusuchen.
Richtig ist der Satzanfang, TRIM spielt ihm zu und er weiß dann nach dem Löschen der Datei sofort, deren Blöcke können ab jetzt weg. Aber ohne TRIM hat er auch eine Möglichkeit zu erfahren, dass die Daten Müll sind, nur eben nicht sofort. Er weiß diese in dem Moment, wo wieder auf die Sektoren geschrieben wird. Bei einer HDD wären die alten Daten damit ja überschrieben, also gelöscht und müssen daher ungültig sein.
Wenn er raten wollte, müßte er die FS Struktur erkennen und das kann er bestenfalls bei NTFS und noch ein ein oder zwei FS machen, aber alleine für Linux gibt es ein Dutzend, nur wenn die ganze Platte nicht cryptographiert ist und nicht im RAID hängt. Also nicht wirklich eine gute Idee.
mumpel schrieb:
TRIM hat also mit der Lebensdauer wenig zu tun. Und ob 50, 34 oder 25 nm hat mit TRIM oder GC auch wenig zu tun. Nur in sofern, dass die Löschzyklen mit kleinerer Struktur drastisch sinken und die GC im besten Fall darauf Rücksicht nehmen sollte.
Die Strukturbreite der NAND Chip hat in der Tat nichts mit TRIM oder GC zu tun, sie stimmt die Eigentschaften des NANDs selbst und je kleiner die Strukturen werden, umso weniger Löschzyklen erreicht man bei gleicher Technik. Da kommt an nicht drum herum.
TRIM erhöht aber trotzdem die Lebensdauer, weil er den Zeitpunkt vorverlegt, wann der Controller weiß welche Daten schon ungültg sind. Damit braucht er diese nicht mehr kopieren, wenn die den Block löscht, in dem sie liegen.
 
Wie bitte, das Update ist schon da aber das Changelog kommt erst noch? Das ist ja ein Hammer, wissen die dann nicht, was die da geändert haben? Sowas habe ich ja noch nie erlebt.
 
Ja, es wird damit begründt, dass das ein früher Release für Enthusiasten ist.
Daher ist die Version auch noch net auf der Homepage eingetragen, da der Changelog noch fehlt.
Bin mir da auch net sicher, ob die Firmware nicht von Sandforce kommt und OCZ die nur durchreicht.

Gruß
 
Sind die Release Notes der 1.29 veröffentlich? Ich vermute die werden die Unterstützung für die 25nm 32GBit NANDs enthalten, die man ja in den ausgetauschten 55er und 115er einbauen wird und mehr nicht. Sollte keine Release Notes auftauchen, dann stärkt das sowohl meine Vermutung als auch die Missgefallen am Verhalten von OCZ. Was haben die denn in den Releasenotes zu verbergen?
 
Zuletzt bearbeitet:
Da man auch keine für 1.25, 1.26 und 1.27 veröffentlicht hat, aber zumindest die 1.25 und die 1.27 ausgeliefert wurden, wäre es nicht wirkklich verwunderlich, wenn auch keine mehr erscheint. Da sowas für mich kein seröses Verhalten ist, weiß ich von welcher Firma ich keine Produkte mehr kaufen werde.
 
da OCZ sehr viele unterschiedliche Nand-Typen einsetzt, brauchen die nunmal für jeden Hersteller eine eigene Firmware, in den letzten Vertex 2 waren die billigen 32nm Chips von Hynix drin, die brauchen natürlich eine andere FW wie die 34nm von Micron, ist doch klar. Wer also 34nm Chips hat braucht keine FW für 32nm.
 
Fixed rare corner case that could cause the drive to reset and clear user data
sehr beruhigend zu wissen :evillol:
Und immer noch 10 bekannte, ungelöste Probleme, aus denen wohl irgendwo auch eines für das Problem mit dem S3 (Sleep) verantwortlich ist, oder verschweigt man das lieber in der Release Notes?
 
@Holt,
Für mich zeugt es von Seriosität wenn man auch seine Schwächen kennt.. Es ist ganz einfach ehrlich..
Jedes Produkt beinhaltet schwächen in irgendeiner Hinsicht... (.. auch wenn das gewisse FanBoys nicht wahrhaben wollen.. ;) )
 
@Boeby , du redest allenernstes im Zusammenhang mit OCZ von Ehrlichkeit?
OCZ ist eine der gierigsten,kundenunfreundlichsten Firmen in der IT Welt.
 
@Stany,
Ja so macht es mir den Eindruck.
(Aber dann liege ich wohl daneben.. So war nur mein Eindruck der Firma..)
 
Hallo Leute,

ich will meine Festplatte auch in Kürze durch eine SSD ersetzen. Windows 7 wäre das BS.
Es würde auch einige Spiele drauf installiert werden. (BF BC2, MoH, Crysis etc)
Ich schwanke zwischen der OCZ Vertex 2 180GB oder der Crucial RealSSD C300 128GB.
P/L pro GB ist die OCZ natürlich besser, bietet aber nur SATAII und niedrigere Leseraten als die Crucial. Dafür ist die OCZ beim schreiben schneller und P/L besser.
Was würdet Ihr sagen?
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben