Re: SSD : prüfen ob trim-Unterstützung funktioniert und Parameter für fstab
Am Samstag, 1. Dezember 2012 schrieb Andre Tann:
> Michael Schuerig, Freitag, 30. November 2012:
>
> > > Dann ist die aber einen anderen Tod gestorben als den, den
> > > Überbeanspruchung durch dauerndes Schreiben hervorruft.
> > > Elektronische Komponenten sterben eben manchmal.
> >
> >
> >
> > Wir wissen es beide nicht und in der Wirkung ist es gleichgültig.
>
> Nicht ganz, wenn meine Annahme stimmt, daß der Überlastungstod dazu
> führt, daß man noch lesen kann. Aber das sei sekundär, eine Backup muß
> so oder so sein.
Andre, hast Du da irgendwelche Quellen, Belege oder Ähnliches für?
Ich finde Deine Annahme ja durchaus logisch und ich würde SSDs auch so
bauen, doch mit meinem Hintergrundwissen zur Technik denke ich, dass die
Firmware von guter Qualität sein muss, damit das hinhaut.
Warum?
Du bzw. das von Dir verwendete Betriebssystem ist nicht der einzige, der
Daten schreibt.
Übliche SSD-Firmwares kopieren Daten um. Ich kenne dafür zwei Gründe:
1) Wear Leveling: Du kopierst ein 8,ebbes DB DVD DL Image auf die SSD und
fasst das nie mehr an. Weiterhin schreibst Du, schreiben Anwendungen ein
Haufen von Daten. Die Erase Blöcke für das Image sind nur einmal
beschrieben, während die anderen Erase Blöcke immer wieder gelöscht und
beschrieben wurden. Diese Ungleichgewicht würde dazu führen, dass einige
Erase Blöcke wesentlich schneller kaputt gehen als andere. Die Firmware
kopiert daher irgendwann das DVD-Image, das Du selbst gar nicht mehr
schreibend anfasst, woanders hin. Das macht sie im Idealfall dann, wenn Du
nicht groß was von merkst. Nun sind DVD-Images ohnehin nicht der ideale
Anwendungszweck für SSDs, aber las es Fotos sein oder irgendwas anderes,
was Du nicht mehr anfasst.
2) Garbage Collection: Die Firmware kombiniert Schreibvorgänge zusammen,
um Erase Blocks möglichst gut auszunutzen. Daher liegen Datei A und Datei
B vielleicht auch einem Erase Block. Du löschst Datei A. Der Erase Block
ist nur noch teilweise genutzt. Den ungenutzten Bereich kann die Firmware
aber nicht beschreiben, da sie dazu den ganzen Block löschen müsste. Also
fängt die Firmware irgendwann an, Daten aus teilweise genutzten Erase
Blöcken so zusammen zu verschieben, dass sie wieder Erase Blöcke freigeben
kann.
Der Idealfall wäre nun:
Die Firmware kopiert nur dann Daten um, wenn sie vorher sichergestellt
hat, dass genügend freie *und* bereit erfolgreich gelöschte Erase Blöcke
existieren.
Wie gesagt, ich würde das so machen.
Aber auch dann würde die Performance der SSD wahrscheinlich in den Keller
gehen, bevor sich gar nichts mehr schreiben oder intern durch die Firmware
umkopieren läßt. Da Du die Umkopier-Aktivitäten der SSD-Firmware in einem
solchen Fall nicht einfach stoppen kannst, könnte das auch die
Geschwindigkeit von Lese-Zugriffen verringern, wenn die Firmware versucht,
aus den letzten Erase Blocks herauszukratzen, was noch geht.
Die Performance würde vor allem bei länger anhaltenden, massiven
Schreibzugriffen in den Keller gehen, bis die SSD sich durch Wear Leveling
und Garbage Collection wieder etwas erholt hat.
Ding ist: Ich könnte die SSD dann ja tauschen, wenn sie langsam wird, also
noch bevor sie gar nichts mehr schreiben kann. Inwiefern ich sie dann auf
Garantie ersetzt bekomme? Das kommt wohl auch auf die Kulanz des
Herstellers an. Oder ich warte, bis wirklich keine Schreibzugriffe mehr
gehen, die SSD also eindeutig kaputt ist, und hoffe, dass die Firmware das
so handhabt, wie oben beschrieben, anstatt auf eine kreative Weise auf die
Schnauze zu fallen, weil vielleicht Programmierfehler drin sind. SSD-
Firmwares sind Binärblobs, in die Open-Source-Entwickler ohne NDA keinen
Einblick haben.
Ja, da ist auch etwas Spekulation und Raten drin. Genau deshalb würde mich
das mal interessieren. Was passiert, wenn eine SSD nicht mehr schreiben
kann? Hast Du da was zu gelesen? Mir ist da bislang nichts zu
untergekommen und ich habe Einiges zu SSD gelesen.
Bei USB-Sticks hörte ich im Zusammenhang mit FAT32 und der sync-Mount-
Option, dass da einige durch die vermehrten Schreibzugriffe, einfach flöten
gingen. Also kaputt im Sinne von kaputt. Allerdings habe ich auch da keine
eindeutigen Referenzen zu, ob das auch Lese-Zugriffe betrifft.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: