Das Ende der alten Festplatten
-
BTW: Vielleicht ist das da im Kontext dieses Threads auch ganz interessant:
-
mausekäbel schrieb:
Kann man die auch zum Entwickeln verwenden, oder gehen die zu schnell kaputt bei so vielen schreibzugriffen?
Das hängt davon ab, ob du > 1 Million Schreibzugriffe erreichst.
Umso größer die Festplatte umso mehr Schreibzugriffe sind machbar, weil das alles über den Chip schön verteilt wird.
Du solltest aber ein OS mit Trim Support haben.
Also mindestens Windows 7 oder Linux ab Kernel 2.6.33 (der auch erstmal rauskommen muß)
-
Gregor schrieb:
BTW: Vielleicht ist das da im Kontext dieses Threads auch ganz interessant:
Geil, so ein SSD Chip eignet sich als Farbspektrometer.
Dann kann ich mein Prisma ja wegschmeißen und mir in Zukunft so nen Chip kaufen.
Ich bräuchte ihn ca. 6 cm * 2 cm groß.
-
SSD2 schrieb:
Du solltest aber ein OS mit Trim Support haben.
Also mindestens Windows 7 oder Linux ab Kernel 2.6.33 (der auch erstmal rauskommen muß)TRIM Support hat keinen so grossen Einfluss auf die Haltbarkeit.
@mausekäbel:
Ja, kann man.
BTW: was meinst du mit "so viele Schreibzugriffe"? Die paar Megabyte die geschrieben werden wenn ich auf "compile" drücke?
-
hustbaer schrieb:
BTW: was meinst du mit "so viele Schreibzugriffe"?
Wahrscheinlich meint er das krankhafte drücken von <Ctrl>+<S> nach jeder geänderten Zeile
Grüssli
-
SSD2 schrieb:
oder Linux ab Kernel 2.6.33 (der auch erstmal rauskommen muß)
sollte TRIM nicht schon seit 2.6.28 enthalten sein?
-
hustbaer schrieb:
@mausekäbel:
Ja, kann man.
BTW: was meinst du mit "so viele Schreibzugriffe"? Die paar Megabyte die geschrieben werden wenn ich auf "compile" drücke?Wenn ich das ganze Projekt in der Arbeit compiliere, ist das schnell mehr als 1GB an pbds usw.
Auf was beziehen sich die 1 Million Schreibzugriffe? 1 Million mal jedes einzelne Byte? 1 Million mal was schreiben?
-
mausekäbel schrieb:
Auf was beziehen sich die 1 Million Schreibzugriffe? 1 Million mal jedes einzelne Byte? 1 Million mal was schreiben?
Wenn man einzelne Bitzellen betrachtet, dann kann man ganz gut die Daten der "International Roadmap for Semiconductors" nehmen. Die aktuellen Daten sind in der Tabelle da enthalten:
http://www.itrs.net/Links/2009ITRS/2009Chapters_2009Tables/2009Tables_FOCUS_B_ITRS.xls
...und zwar unter dem Punkt "Current Baseline and Prototypical Memory Technologies". Da steht bei Flash Speicher (bzw. Floating Gate Speicher), dass die Anzahl der Schreibzyklen bei >100.000 liegt. Also eher weniger als 1 Mio. Zyklen.
-
Gregor schrieb:
...und zwar unter dem Punkt "Current Baseline and Prototypical Memory Technologies". Da steht bei Flash Speicher (bzw. Floating Gate Speicher), dass die Anzahl der Schreibzyklen bei >100.000 liegt. Also eher weniger als 1 Mio. Zyklen.
Aber nur einzelne Bitzellen zu beachten ist wohl nicht sinnvoll um zu erheben, wie lange eine SSD bequem beschreibbar ist; SSDs haben ja auch Reserven wegen Wear Levelling und zur Verhinderung der Fragmentierung und zur sector relocation (wie sie normale HDDs ja auch haben).
Dadurch sollte sich die Anzahl der Schreibzyklen doch nochmal kräftig nach oben verschieben, oder?
-
Nochmal der Verständnis halber:
ich habe es bisher immer so verstanden, dass Wear Levelling so funktioniert, dass bei einem anstehenden Schreibvorgang auf einen überdurchschnittlich genutzten Block stattdessen das Ganze lieber auf einen weniger genutzten Block umgeleitet wird. Wenn dieser nicht als frei markiert ist (entweder noch nie beschrieben oder durch TRIM), wird er vorher in den anderen Block kopiert.
Das scheint für mich auch die einzig sinnvolle Umsetzung zu sein.Wenn dem aber so ist, wieso wird dann ständig von limitierten Schreibzyklen gesprochen und warum wird vielerorts ein non-journaling Dateisystem wie ext2 für SSDs empfohlen? Ist doch vollkommen egal, wenn der Journaling-Bereich ständig beschrieben wird, der sollte sich mit Wear-Levelling ja ständig auf immer wieder anderen Blöcken befinden. Im Idealfall kann man dann schon auf eine 80 GB-SSD bei 100,000 Schreibzyklen pro Zelle insgesamt 8 PB schreiben.
Das ist doch deutlich mehr Durchsatz, als man von einer konventionellen Festplatte während ihrer Lebenszeit je erwarten kann. Bei 24/7-Betrieb und 10 MB/s durchschnittlicher Schreibrate sind das schon 25 Jahre, realistisch sind bei moderatem Nutzungsprofil übers Jahr verteilt aber eher 5-20 KB/s.
Es ist daher auch bei MLC-Chips doch völlig irrealistisch, das Schreiblimit je zu erreichen, da geht längst vorher was anderes kaputt und schon lange vorher hat man sich eine neue angeschafft...
-
Bei MLC Speicher sind es AFAIK eher 10k Schreib-Zyklen, und nicht 100.
Aber auch 10.000 * 64GB sind viel.@mausekäbel:
Milchmädchenrechnung:Wenn du pro Compilieren 1 GB schreibst, dann wären es 640.000 Compiliervorgänge die das Ding aushält - bei einer 64GB SSD mit optimalem Wear-Leveling.
Sagen wir sicherheitshalber es sind 10 GB und nicht 1 GB. Wären es immer noch 64K Compiliervorgänge.Wenn du am Tag 100x einen kompletten Rebuild machst, hält die Platte immer noch ~2 Jahre. Wenn ich mich nicht verrechnet habe, würde das reine Schreiben dieser Datenmenge schon fast 3 Stunden brauchen (100 * 10 GB, bei ca. 100MB/sec -> 10.000 sec -> 2,78 Stunden).
Da ich davon ausgehe dass du LANGE nicht 100 Rebuilds pro Tag machst, sehe ich da kein Problem.
Wenn dem aber so ist, wieso wird dann ständig von limitierten Schreibzyklen gesprochen und warum wird vielerorts ein non-journaling Dateisystem wie ext2 für SSDs empfohlen? Ist doch vollkommen egal, wenn der Journaling-Bereich ständig beschrieben wird, der sollte sich mit Wear-Levelling ja ständig auf immer wieder anderen Blöcken befinden.
Weiss nicht. Vielleicht saufen die Leute alle die sowas schreiben. Vielleicht ist das Wear-Leveling aber auch nicht SO perfekt. 100% perfekt kann es IMO auch nicht sein - zumindest nicht ohne die Write-Amplification zu sehr hoch zu treiben. Und die will man ja auch niedrig halten.
Trotzdem gehe ich davon aus, dass eine SSD effektiv "lange genug" hält. Egal ob MLC oder SLC, egal ob man nun viel Compiliert oder nicht. Ausnahmen fallen mir jetzt kaum welche ein. Vermutlich irgendwelche sehr speziellen Server-Anwendungen.
