Benchmarks für wirklich volle SSDs (ohne Trim)?

[stacker2]

Gibt's irgendwo einen Testbericht, der günstige SSDs (MLC bis 200 Euro) in richtig vollem Zustand testet? Meist sind die Berichte ja vom Typ
"leer haben wir folgende Benchmarks gemessen, voll wird's wohl etwas schlechter"
was mir gar nichts bringt, sowie
"leer haben wir folgende Benchmarks gemessen, einmal alle Zellen beschrieben (aber nicht 100% Speicher wirklich als belegt markiert) haben wir folgende Benchmarks gemessen"
was auch nicht wirklich aussagekräftig ist. Besonders wenn das SSD Trim macht, sind diese Zahlen nichts mehr wert.

So wie ich meine SSD vorhabe zu betreiben und bei meinem Betriebssystem, wird sie stets 100% vollgeschrieben sein (die Zellen, nicht das Dateisystem) und niemals irgendein Trim machen.

 

[schweiger]

ich fürchte bei deinem Vorhaben, sind die Indilinx oder Intel SSD nicht die richtigen. Da müsstest du auf SSDs setzen, die mit der herkömmlichen Controller-Technologie arbeiten, wie z.B. Mtron, die bleiben durchgängig gleich schnell, aber die gibts nur als SLC

 

[antiram]

du kannst auch einfach eine doppelt so große ssd nehmen und nach secure erase nur 50-60% partitionieren. Das ist dann so wie 40-50% getrimmt.
http://www.hardwareluxx.de/community/showpost.php?p=12215980&postcount=804
http://www.hardwareluxx.de/community/showthread.php?p=13214607&highlight=iozone#post13214607

 

[Shagnar]

wie soll das gehen?

das problem sind doch dann imemrnoch zellen, die erst gelöscht werden müssen bevor man schreiben kann.

 

[antiram]

der controller weiß dann, das 40-50% der Zellen ungültige Daten haben oder leer sind. Lies einen Sektor der noch nie beschrieben wurde, da kommen Nuller zurück

root@locutus:~# hdparm --read-sector 250000000 /dev/sda

/dev/sda:
reading sector 250000000: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
usw

 

[stacker2]

der controller weiß dann, das 40-50% der Zellen ungültige Daten haben oder leer sind. Lies einen Sektor der noch nie beschrieben wurde, da kommen Nuller zurück

root@locutus:~# hdparm --read-sector 250000000 /dev/sda

/dev/sda:
reading sector 250000000: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
usw

Aber es sind doch alle Sektoren beschrieben? Auch bei nur 50% Partitionierung. Bei mir werden in kurzer Zeit viel mehr Daten auf das Gerät geschrieben als man braucht um das 1mal (oder auch 2mal, 3mal ...) zu füllen.

 

[Sukrim]

Ja und? Dennoch werden nur 50% dieser beschriebenen Blöcke auch dem OS auf Anfrage ausgegeben, der Rest kann im Notfall ohne vorher gelesen werden zu müssen überschrieben werden da die Daten ohnehin veraltet/unnütz sind.

 

[Shagnar]

ja, aber gelöscht werden muss er ja trotzdem unmittelbar vor dem kopieren.

 

[Shock3d]

@stacker2
MLC und unter 200euro ohne Trim wird dir keine Freude bringen, also ich Trimme meine ST UD quasi jeden Tag sobald ein paar mal etwas de/installiert wurde und die Geschwindigkeit ändert sich dadurch schon sehr.

 

[pinki]

wie? bei dir ändert sich die geschwindigkeit wenn du was de/installierst?
also das bezweifle ich doch mal, es sei denn du fährst deine U bereits auf der letzten rille was freien speicher angeht.

 

[antiram]

die SSDs arbeiten den ganzen tag und können auch in der idlezeit
1. blöcke, die nur aus ungültigen Daten bestehen löschen
2. blöcke die gültige und ungültige Daten enthalten zu blöcken zusammenfassen, die ausschließlich aus gültigen oder ungültigen Daten bestehen. goto 1

wenns um linux geht kann man auch nur /home und /var auf einen verschlüsselten container legen, dann kann man den rest trimmen. Bei Ubuntu soll es auch die Möglichkeit geben ein verschlüsseltes Verzeichnis in /home/username beim installieren einzurichten.
wenns bloß um lineares LVM geht kann man das wiper.sh auch für die eigenen Bedürfnisse zurechtfrickeln
http://www.ocztechnologyforum.com/forum/showthread.php?p=421517#post421517

 

[Shock3d]

wie? bei dir ändert sich die geschwindigkeit wenn du was de/installierst?

Ganz genau so sieht es aus. Nachfolgenden sind zwei schnelle Benches, habe vorgestern Supreme Com installiert, weil ein Kumpel das mit mir zocken wollte, damit waren nur noch 15GB frei. Der erste Bench ist unterdiesen Bedingungen und der zweite ist nach dem deinstallieren und Trimmen.
Wenn genüngend Platz frei ist, bleibt die Geschwindigkeit natürlich gleich, wenn man trimmt, ab einer gewissen Grenze hilft Trimm auch nichts.

 

[stacker2]

ich fürchte bei deinem Vorhaben, sind die Indilinx oder Intel SSD nicht die richtigen. Da müsstest du auf SSDs setzen, die mit der herkömmlichen Controller-Technologie arbeiten, wie z.B. Mtron, die bleiben durchgängig gleich schnell, aber die gibts nur als SLC

Mich interessiert nicht im geringsten, ob die SSD beim Schreiben den Anfangswert behält (tut eine MLC ja auch nie). Es ging nur darum dass von den beiden Zahlen
(a) Schreibgeschwindigkeit anfangs
(b) Schreibgeschwindigkeit im richtig vollen Zustand
für mich (a) genau 0% Relevanz hat und (b) genau 100% Relevanz hat, und ich einen Bench sehen will, wo ich (b) nach lesen kann.

Übrigens kann dieser Wert (also (b) ) auch mittelmäßig sein, das reicht ja immer noch zum schnellen Booten und für Dateisysteme wie /usr wo sowieso nix geschrieben wird.

 

[DoubleJ]

die SSDs arbeiten den ganzen tag und können auch in der idlezeit
1. blöcke, die nur aus ungültigen Daten bestehen löschen

Nein, das können SSDs nicht. Ohne TRIM bekommen sie keine Informationen darüber, welche Daten wichtig sind und welche nicht und können demnach auch nicht einfach irgendwelche Blöcke löschen. Das einzige, was SSDs ohne TRIM machen, ist die Blockfragmentierung zu minimieren. Dabei werden aber auch verwaiste Daten hin- und hergeschoben, gelöscht wird nie etwas.

 

[stacker2]

Nein, das können SSDs nicht. Ohne TRIM bekommen sie keine Informationen darüber, welche Daten wichtig sind und welche nicht und können demnach auch nicht einfach irgendwelche Blöcke löschen. Das einzige, was SSDs ohne TRIM machen, ist die Blockfragmentierung zu minimieren. Dabei werden aber auch verwaiste Daten hin- und hergeschoben, gelöscht wird nie etwas.

Ich glaube, antiram meint, die SSD kann den unpartitionierten Bereich nutzen, um diesen zu nullen, dann dorthin zu schreiben statt in den partitionierten, und danach die entsprechende Stelle im partitionierten Bereich dem unpartitionierten zuordnen und bei Gelegenheit nullen.

Ich glaube eher nicht, dass SSDs das so machen, das hätten wir wohl als Werbeaussage schon gehört.

 

[DoubleJ]

Die SSD weiß auch nichts von Partitionen auf ihr, dazu müsste der Controller ja ein Dateisystem lesen können*. Natürlich werden alle Zellen benutzt, also auch die "unpartitionierten". Aber sobald eine 120 GB SSD mit 120 GB beschrieben wurde - egal ob die Partition die komplette SSD ausfüllt oder nur 10 GB groß ist - sind alle Zellen einmal beschrieben und alle Daten werden als "wertvoll" behandelt.
Ab diesem Zeitpunkt geht es einem nicht TRIM-fähigen Controller nurnoch darum, Blockfragmentierung zu beseitigen.

(* Einzige Ausnahme ist Samsungs RBB Controller, der kann NTFS lesen und nicht meht genutzte Daten auch ohne TRIM löschen)

 

[Sukrim]

Aber sobald eine 120 GB SSD mit 120 GB beschrieben wurde - egal ob die Partition die komplette SSD ausfüllt oder nur 10 GB groß ist - sind alle Zellen einmal beschrieben und alle Daten werden als "wertvoll" behandelt.

Genau das glaube ich eben nicht, da bei einer 10 GB Partition auch nur 10 GB der SSD-Blöcke wertvolle/sinnvolle Daten beinhalten. Der Controller muss ja wissen, welche Datenblöcke der 120 GB (10 GB wurden 12 Mal beschrieben/geändert) aktuell sind, also können die restlichen 110 GB locker verworfen werden, da sie ja nie mehr abgefragt werden (das weiß der Controller ebenfalls).

 

[DoubleJ]

Aber woher soll der Controller denn wissen, wann er die Daten verwerfen soll?
Er kann Daten ja nur verwerfen, wenn sie gelöscht werden. Aber eben genau davon bekommt ein Controller ohne TRIM nichts mit (Ausnahme Samsung).

 

[Sukrim]

Sobald das Betriebssystem sagt "schreib Daten in Block 1234" obwohl dort schon Daten drinnen stehen (was beim Überschreiben ja vorkommt...)

 

[DoubleJ]

Ja, dann ist es aber "zu spät". Der Controller muss es eben wissen, sobald die Datei gelöscht wurde, nicht erst, wenn die neuen Daten geschrieben werden. Beim Überschreiben bringt außerdem auch TRIM nichts.

 

[Sukrim]

Du hast doch gerade geschrieben, dass SSDs nach mehrfachem Überschreiben derselben Daten diese immer noch als wichtig ansehen und daher die (in deinem Beispiel) verbleibenden 110GB auch mit Nutzdaten "zumüllen" die angeblich als erhaltenswert angesehen werden.

Meiner Meinung nach kann ein Controller auch dann Daten verwerfen, sobald er neue Daten in denselben Block schreiben muss, daher wäre es durchaus möglich, dass ein großes SSD mit Minipartition nicht einbricht - auch wenn es oftmals überschrieben wurde. Daher zweifle ich deine Aussage "sobald 120 GB geschrieben wurden ist das SSD langsam" an.

Dass TRIM sinnvoll ist usw. ist mir klar und bestreite ich auch nicht - mir geht's eben um genau diese eine Behauptung.

 

[DoubleJ]

Ich versteht gerade wirklich nicht, worauf du hinauswillst Wenn der Controller neue Daten in den gleichen Block schreiben soll, gibts ein read-modify-write. Welche Daten sollen da verworfen werden? Nochmal: Der Controller kann und darf auch keine Daten verwerfen. Fertig. Und wenn eine SSD mit der Größe X mit X Daten gefüllt wurde, ist jede Zelle beschrieben und wird so vom Controller behandelt. Und wenn neue Daten kommen, kommen halt neue Daten: read-modify-write. Verworfen wird da nichts.

 

[sanic]

@stacker2
du schreibst in deinem ersten Post "und niemals irgendein Trim machen"

das brauchst du auch nicht machen, wird alles automatisch erledigt (Intel). Es reicht schon wenn du mal dein papierkorb entleerst oder was löschst. Ansonsten wie schon erwähnt Mtron SLC SSDs.

 

[Sukrim]

Und wenn neue Daten kommen, kommen halt neue Daten: read-modify-write. Verworfen wird da nichts.

Meiner Meinung nach kommen neue Daten ohne vorherigen Read und Modify in Zellen, die zwar beschrieben wurden aber als "Datenmüll" (da die aktuellen Daten längst woanders liegen) gekennzeichnet sind.

Edit:

Beispiel:
10 Block SSD
1 Block vom OS formatiert, 9 frei.

OS sagt: "Schreib was in Block 1"
SSD denkt: "mein Block 3 ist wenig genutzt, da kommt's rein - sobald das OS fragt, kriegt's den Inhalt von Block 3 präsentiert"
OS sagt: "Schreib was in Block 1"
SSD denkt: "oha, naja, jetzt nehm ich Block 4, der passt mir gerade - wenn das OS fragt kriegt's dann Block 4 präsentiert"
OS sagt: "Schreib was in Block 1"
SSD denkt: "gleiches Spiel, diesmal mit Block 7"
.
.
.
OS sagt: "Schreib was in Block 1"
SSD denkt "mein Block 3 ist ja schon längst out-of-date, aktuell ist der OS-Block 1 ja mein Block 9 - ab mit den Daten nach Block 3" <-- und genau da muss eben NICHTS geTRIMt, erhalten, gelesen, geändert oder sonstwas werden. Einfach den Block von vorne bis hinten neu beschreiben, egal was vorher drinnen war.

 

[stacker2]

@stacker2
du schreibst in deinem ersten Post "und niemals irgendein Trim machen"

das brauchst du auch nicht machen, wird alles automatisch erledigt (Intel). Es reicht schon wenn du mal dein papierkorb entleerst oder was löschst.

Bei mir gibt's keinen Papierkorb, kein Windows und (aus Sicht der SSD) kein Dateisystem. Ich will die SSD nur als Blockdevice ansprechen. Für ein Blockdevice schickt das OS keine Trim-Kommandos an die SSD. Die SSD kann also niemals irgendein Trim machen, selbst wenn die SSD-Firmware dies unterstützt.

Ansonsten wie schon erwähnt Mtron SLC SSDs.

SLC ist für mich preislich völlig uninteressant.

Wie schon gesagt, interessiert mich das Verhältnis neu/gebraucht bei der Schreibgeschwindigkeit rein gar nicht. Die darf ruhig stark abfallen. Nur muss sie danach eben noch hoch sein. Und genau dass will ich gebencht sehen.

Die Diskussion hier gerade (hilft eine doppelt so große SSD) ist aus theoretischer Sicht extrem interessant. Wird mir persönlich aber nicht helfen, da ich bei aktuellen Preisen nicht mal so eben doppelt soviel kaufen kann. Lasst euch aber nicht von der Diskussion abhalten, die ist gerade spannend.

 

[Grummel]

Ich habs spaßeshalber mal gestest.

47% Füllung (Systemplatte - Win XP mit Programmen/Spielen):



99% Füllung, nur noch 280 MB frei:



Nimmt sich nichts. Ist aber auch eine SLC.

 

[sanic]

wo ist den das problem, eine Intel MLC holen, und fertig auch ohne TRIM. Bis einer gewissen Grenze wird die anbrechen und des wars. Ist dann trotzdem noch schneller als manche andere SSDs getrimmt.

 

[Sukrim]

Nimmt sich nichts. Ist aber auch eine SLC.

Dann schau mal Intel SLC Modelle an...

Der "Trick" bei Mtrons liegt nicht im Flash sondern einfach daran, dass die Dinger kein Write-Combining beherrschen. Wo nichts fragmentiert wird, wird nichts langsamer.

 

[sanic]

ja nur die leistung der Intel SLC ist mtrons überlegen, auch ungetrimmt

 

[Grummel]

Dafür hat meine auch nur 80 Euro gekostet und die Intel SLC... hmmh, ein paar Euro mehr.

Mein Mainboard kann übrigens nicht schneller als 82 MB/s, deshalb sehen die sequentiellen Raten, die in der Realität je eh meist irrelevant sind, so mickrig aus.