SSD Reboot

Storage & Speicher | HT4U.net | Seite 3

Die Wurzel allen Übels: Read-Modify-Writes


Was passiert, wenn alle Seiten in allen Blöcke mit aktiven oder veralteten Daten belegt sind und nur die Daten einer Seite geändert werden müssen? Dann muss der Controller folgenden Prozess durchführen:
  • lese alle Seiten des Erasable Blockes aus
  • schreibe sie in einen Zwischenspeicher (Spare Area oder RAM auf der SSD)
  • ändere die Daten der zu ändernden Seite
  • lösche den erasable Block, in dem sich die Daten vorher befanden
  • schreibe die alten Seiten und die Seite mit dem geändeten Inhalt in den Block

Diese Read-Modify-Write-Prozedur sorgte in den Anfangszeiten der SSDs für starken Verdruss bei den Nutzern, welche Leistungsabfälle bei ihren teuren SSDs feststellten, nachdem sie eine Weile in Benutzung waren. Abgesehen vom Zeitaufwand bedeutet es auch, dass eine SSD z.B. für die Änderung einer 4 KiB-Datei (die Seite) insgesamt 512 KiB (den Block) schreiben müsste. Diesen Mehraufwand nennt man Write Amplification und da er zu Lasten der Speicherzellenhaltbarkeit geht, versucht der Hersteller ihn möglichst zu vermeiden. Das Grundproblem ist, dass in dem Moment nicht ausreichend leere Seiten zur Verfügung standen, weil veraltete Daten wertvolle Seiten und Blöcke belegen. Die Lösung: erst einmal den Müll rausbringen!

Müllabfuhr


Der eben beschriebene Worst Case muss also verhindert werden und dazu trägt die Garbage Collection (zu Deutsch: Müllabfuhr) bei. Diese versucht durch umorganisieren der Daten freie Blöcke zu schaffen, damit diese gelöscht werden können und zum direkten Beschreiben ohne Read-Modify-Write-Zeitverzug wieder bereitstehen. Kommen wir als Beispiel zu unserer gedachten SSD zurück: Nehmen wir einmal weiter an, dass auf unserer SSD mittlerweile munter weiter geschrieben und gelesen wurde. Die Folge ist, dass mittlerweile in jedem Block alle Seiten schon einmal beschrieben wurden, also entweder frei (aber nicht leer) sind oder aktive, gültige Daten enthalten.

Bild: SSD Reboot

Eine "Datei 3" wurde zweimal und eine "Datei 4" einmal geändert. Alle Seiten in Block 3 sind daher schon mal beschrieben worden, enthalten aber keine gültigen Daten mehr. Jetzt nimmt der Controller die gültigen Daten aus Block 1 und Block 2 und verschiebt diese in den dritten Block. Diesen kann der Controller vorher ohne Probleme löschen, da dort alle Seiten keine gültigen Daten mehr enthielten.

Bild: SSD Reboot

Nun sind die Blöcke 1 und 2 nicht nur frei, sondern auch leer (komplett entladen) und stehen so für die kommenden Schreibzugriffe sofort zur Verfügung. Die Garbage Collection sorgt also dafür, dass möglichst viele freie und leere Blöcke zur Verfügung stehen, damit kommende Schreibzugriffe ohne zeitaufwändige Read-Modify-Write-Vorgänge schnell abgearbeitet werden können. Es ist letztlich dem SSD-Hersteller bei der Anpassung der Firmware überlassen, nach welcher Strategie er vorgeht. Das eine – eher aggressive – Extrem wäre, dass er jederzeit im Hintergrund die Garbage Collection laufen lässt. Die Vorteile wären dann ein weniger starkes Einbrechen bei plötzlicher hoher Schreiblast, da ständig möglichst viele freie Blöcke zur Verfügung stehen. Der Nachteil ist aber eine höhere Abnutzung der Speicherzellen aufgrund der vermehrten Umsortierung der Daten.

Das andere, eher konservative Extrem wäre, dass der Controller mit der Garbage Collection wartet, bis nur noch eine kleine Anzahl von Blöcken leer ist. Diese Methode führt dafür zu Performanceeinbußen, wenn dann auf einmal plötzlich viele kleine Schreibzugriffe angefordert werden, erhöht aber die Haltbarkeit der Zellen. Der Hersteller muss nun das passende Gleichgewicht finden in Abhängigkeit von der Haltbarkeit der verwendeten Speicherzellen und dem Anforderungsprofil an die SSD.

 



Jetzt kostenlosen HT4U.net-Newsletter abonnieren

* indicates required