Mit den neuen »Solid Dtate Disks (SSD)«¹⁾ kam eine der interessantesten Innovation der letzten Zeit auf den Markt. Die Technologie ist an sich ist nicht neu und wird bereits zB bei USB-Sticks oder Fotokarten schon länger verwendet, jedoch die Technologie in den Bereich der Computerfestplatten zu transferieren, brachte einen enormen Geschwindigkeitszuwachs. Der Anwender bekommt unmittelbar ein Feedback, denn die Zugriffszeiten auf Dateien oder Programme auf seinem Rechner verkürzen sich eklatant. Wenn man diese Technologie aber etwas näher betrachtet, dann stößt man auch auf Probleme, welche uU nicht unerheblich sein können. Dieser Artikel soll in groben Zügen die Funktionsweise einer SSD beleuchten, die Probleme daraus ansprechen und die möglichen Gegenmaßnahmen aufzeigen.

SSD Speicher basieren auf das Prinzip der »Flash-Speicher«²⁾. Informationen werden nicht wie bei herkömmlichen Festplatten durch magnetische Ausrichtung gespeichert, sondern in sogenannten »Flash-Zellen« durch elektrische Ladungen. Im Prinzip kann eine Flash-Zelle eine Informationseinheit (Bit) speichern, jedoch wurden im Laufe der Zeit Zellen entwickelt, welche es erlauben mehr Informationseinheiten in einer Zelle zu speichern. Bei SSD Festplatten kommen sog. »NAND-Zellen«³⁾ zum Einsatz, welche grundsätzlich page- und blockorientiert arbeiten. Das bedeutet, dass mehrere NAND-Zellen zu Pages zusammengefasst werden, welche idR 512B - 4KiB groß sind. Diese »Pages« werden wiederum zu »Blöcken« zusammengefasst, welche, je nach Größe des Datenträgers, 64 oder 128 Pages besitzen. Bei einer modernen SSD Festplatte kommen idR 4KiB Pages und Blöcke mit 128 Pages, was einer Blockgröße von 512KiB entspricht, zum Einsatz. Flash-Speicher besitzen prinzipbedingt die Eigenschaft nur blockweise lesen bzw. schreiben zu können, was sich bei näherer Betrachtung auch als eines der Haupt-Probleme von SSD Festplatten herausstellt.

Solange ein Block vollständig leer ist, muss der Festplattencontroller die Daten nur in den Block schreiben, womit die höchste Performance der SSD zustande kommt. Findet der Festplattencontroller jedoch bereits einige beschriebene Pages im Block vor, muss der gesamte Inhalt des Blockes gelesen und in den Cache geladen werden (READ), dort werden die für diesen Speichervorgang eigentlichen Daten bzw. Pages dazu geladen (MODIFY), der gesamte Block wird gelöscht (ERASE) und der Inhalt aus dem Cache wieder zurück in den Block geschrieben (WRITE). Das hört sich nicht nur umständlich an, es ist umständlich und wird natürlich immer deutlicher bemerkbar, je mehr eine Platte in Benutzung ist, bzw. je weniger freie Blöcke auf einer Platte vorhanden sind.

Dieses »Read-Modify-Erase-Write« Konzept bedeutet, dass Nutzdaten im Laufe ihres Daseins auf einer SSD Platte mehr als einmal auf die Platte geschrieben werden müssen, sei es nun, weil in den Block einfach nur weitere Daten hinzukommen oder weil Platten-interne Optimierungsmechanismen die Daten bzw. Pages mit anderen Pages zusammenfassen und in einen anderen Block verschieben. Das Verhältnis von neu zu schreibenden Daten und bereits vorhandenen Daten, welche mit umgeschrieben werden müssen, entscheidet letztlich über die subjektive Performance einer SSD Festplatte. Wenn zB ein gesamter Block mit 512KiB neu geschrieben werden muss, weil 4KiB neuer Daten hinzukommen, wird die Platte im Bezug auf einen Speichervorgang von 4KiB relativ langsam erscheinen, man spricht auch von einer schlechten »Write Amplification«⁴⁾. Die »Write Amplification« würde in diesem Fall 128 betragen (512 / 4).

Unter dem Begriff »Wear Leveling«⁵⁾ versteht man eine Funktion, welche verhindern soll, dass einzelne, stark frequentierte Bereiche ungleich höher belastet werden, als andere. Da jede NAND-Zelle nur eine bestimmte Lebenserwartung hat, bei einer modernen SSD Festplatte sind das in etwa 10.000 Schreibzyklen, soll durch Waer Leveling eine gleichmäßige Benutzung des gesamten Datenträgers erreich werden.

Da weder das Betriebssystem noch das Dateisystem Kenntnis über die physikalischen Strukturen einer Festplatte hat, sondern diese unter Angabe eines logischen Adressblocks (»LBA«⁶⁾ → Logical Block Address) mit dem Festplattencontroller kommunizieren, kann vom Betriebssystem keine Optimierung bzw. gleichmäßige Abnutzung einer Festplatte durchgeführt werden. Der Festplattencontroller pflegt eine »LBA to PBA Lookup Table« und kennt dadurch die Zuordnung einer LBA mit den zugrunde liegenden physikalischen Blöcken (»PBA« → Physical Block Address). Somit kann der Festplattencontroller dieses LBA Mapping durchaus dynamisch gestalten.

Kommt nun vom Betriebssystem die Aufforderung einen bestimmten Inhalt in eine LBA zu speichern und der Festplattencontroller stößt bei dieser LBA auf einen PBA, welcher bereits Daten enthält, so ließt er nicht die bestehenden Daten aus und löscht den Block, bevor er sie zurückschreiben könnte, sondern schreibt die Daten in einen anderen, leeren Block und verknüpft nun diesen Teil (Sektor/Page) des neuen PBA mit der LBA. Um für spätere Optimierungsmechanismen dann diesen wieder für eine erneute Verwendung vorzubereiten, wird der nun nicht mehr gültige Inhalt des Blocks als gelöscht markiert. So hat sich aus Sicht des Betriebssystems nichts geändert, obwohl die Daten auf der SSD nun ganz woanders untergebracht wurden aber der Festplattencontroller hat Kenntnis darüber erhalten, dass die Pages des ehemaligen Blocks ungültig sind.

Es gibt im Prinzip zwei Arten von Wear Leveling, da wäre einmal das »Dynamic Waer Leveling«, welches nur Pages aus Blöcken verschiebt, welche sich zB nach oben beschriebenen Muster ändern würden, was jedoch den Nachteil hat, dass Blöcke mit statischen Daten, also solche die niemals oder so gut wie gar nicht vom Betriebssystem geändert werden würden, auch nicht von diesem Lastenausgleichsprinzip profitieren würden. Hier springt das »Static Wear Leveling« ein, welches auch Blöcke verschiebt, die sich im Prinzip sonst nie ändern würden.

Durch das Wear Leveling sammeln sich im Laufe der Zeit eine Menge Blöcke an, welche als gelöscht markierte Daten enthalten. Das ganze Konzept würde aber keinen Sinn machen, wenn der Festplattencontroller die Blöcke nicht wieder für ein erneutes Beschreiben vorbereiten würde. Hier kommt die »Garbage Collection«⁷⁾ ins Spiel. Die Garbage Collection tritt im Hintergrund in Erscheinung und sucht nun solche Blöcke, welche als gelöscht markierte Pages enthalten und bereitet diese auf ein erneutes Beschreiben vor, indem der Block entweder ganz gelöscht (quasi genullt) wird bzw. versucht wird, dass der Block so wenig wie möglich gültige Nutzdaten enthält, damit das oben bereits erwähnte Write Amplification so günstig wie möglich ausfällt. Wir erinnern uns, dass eine günstige Write Amplification dadurch erreicht wird, dass so wenig wie möglich alte Daten mit den neuen Daten geschrieben werden müssen.

Das Konzept der Garbage Collection ist ein gut gehütetes Geheimnis der Festplattenhersteller und unterscheidet sich demnach in Güte und Qualität. Nicht nur das wie und warum jetzt Daten im Hintergrund verschoben und gelöscht werden, ist entscheidend für die Erhaltung einer möglichst hohen Performance sonder auch das wann. Unsere Tests haben gezeigt, das bei einer nur wenig gefüllten Platte (~8%) offensichtlich gar keine Optimierung des Speicherplatzes durch die Garbage Collection stattfindet, was auch Sinn machen würde, weil man ja versucht die PBAs möglichst gleichmäßig zu benutzen, um eine gleichmäßige Abnutzung der gesamten Platte zu erreichen. Die Garbage Collection scheint demnach erst dann in Aktion zu treten, wenn ein bestimmter Prozentsatz an benutzten Blöcken erreicht ist, spätestens jedoch dann, wenn jeder PBA mindestens einmal benutzt wurde.

Mit der Eigenschaft, die Festplatte mit möglichst vielen freien Blöcken zu versorgen, ist die Garbage Collection eine der Hauptkomponenten, wenn es um die Erhaltung der Performance einer SSD Festplatte geht, jedoch hat sie für sich alleine gestellt einen gravierenden Nachteil. Wie oben beim Wear Leveling schon erwähnt, bekommt der Festplattencontroller erst dann Kenntnis davon, welche Pages gelöscht werden können, wenn vom Betriebssystem die Aufforderung kommt Daten in eine bestimmte LBA zu speichern, weil dadurch der alte Inhalt offensichtlich nicht mehr gebraucht wird. Zwar hat die Garbage Collection immer noch einiges zu tun, weil das Wear Leveling bereits einiges als gelöscht markiert aber gerade bei stark frequentierten Systemen mit hoher Datenfluktuation bleibt doch einiges erst mal unbemerkt. Dadurch passiert es dann natürlich relativ häufig, dass durch die Garbage Collection Pages mit zusammengefasst und verschoben werden, welche eigentlich aus Sicht des Dateisystems schon gelöscht wurden.

An dieser Stelle setzt das »ATA TRIM«⁸⁾ Kommando ein. Dieses Kommando muss sowohl vom Betriebssystem, wie auch vom Dateisystem und vom Festplattencontroller unterstützt werden. Bei Linux ist das zB erst ab Kernel Version 2.6.33 und auf ext4 Dateisystem der Fall. Wird nun durch das Betriebssystem eine Datei gelöscht, werden mit der Angabe der zu löschenden LBAs nicht nur diese an das Dateisystem weitergegeben, sondern auch an den Festplattencontroller. Somit weiß der Festplattencontroller bereits dann, welche seiner Pages ungültig geworden sind, wenn der Inhalt vom Betriebssystem (bzw vom Anwender) tatsächlich gelöscht wird und muss nicht erst warten, bis das Betriebssystem einen Bereich überschreiben möchte, von dem es die Information hat, dass dieser eigentlich wieder leer bzw. verwendbar sein sollte.

In vielen Foren und Erklärungen kann man herauslesen, dass TRIM eine eigene Löschroutine besitzt, welche unabhängig von der internen Garbage Collection handelt, was so allerdings nicht stimmt. TRIM optimiert lediglich die SSD-interne Garbage Collection, zT sogar erheblich, je nach Verwendungszweck des betroffenen Rechners.

Verwandte Artikel:
-> Win 7; W2K8R2: Auto-Defragmentierung bei Verwendung von SSD deaktivieren
-> Advanced Format Festplatten
-> Festplatten mit chkdsk überprüfen
-> Festplattengeometrie
-> Cluster: Windows Einheit auf Datenträgern

— pronto 2011/08/05 14:29