SSD Festplatten (Solid State Drive¹⁾) gehören derzeit zu den wohl interessantesten Innovationen im PC-Bereich. Sie erhöhen die I/O Performance um ein Vielfaches und geben somit dem Anwender direkt ein Feedback, was aus seiner, derzeit nicht unerheblicher, Investition geworden ist. Aber SSD-Festplatten sind nicht frei von Problemen und ein eklatantes Problem offenbart sich uU erst viel später und kann den Zuwachs an I/O Performance empfindlich einschmelzen lassen.

SSDs kommen ohne mechanische Bauteile aus und sind daher sehr leise und stoß-unempfindlich, sie sind sehr effizient in ihrem Energieverbrauch haben aber jedoch den Nachteil, dass sie derzeit sehr teuer sind und es bislang nur relativ kleine Platten gibt (≥ 512GB). Ein weiterer Nachteil liegt im Handling von gelöschten Daten. Ein Löschkommando eliminiert erst mal nur den Eintrag im Inhaltsverzeichnis des Dateisystems auf der Festplatte, die eigentlichen Daten bleiben aber erst mal erhalten. Das war bislang bei konventionellen Platten auch schon so, jedoch wurde bei einer erneuten Schreibaktion eines bereits beschriebenen Sektors lediglich die magnetische Ausrichtung geändert, unabhängig davon, ob in diesem Sektor zuvor schon mal Daten gewesen sind oder nicht.

Anders verhält es sich bei SSD Festplatten. SSDs bestehen aus Millionen kleiner NAND Zellen (Flash Speicher²⁾), welche in Gruppen, die Pages genannt werden, organisiert sind. Eine Page ist idR 4KB groß und besteht aus einer Vielzahl von NAND Zellen. Löschoperationen hingegen werden in Blöcken, welche idR aus 128 Pages (512KB) bestehen, durchgeführt. Das wirft das Problem auf, dass die SSD Platte dazu neigt sehr rasch mit benutzen Pages voll zu laufen, weil im Prinzip gewartet werden müsste, bis alle 128 Pages im Block gelöscht worden wären, um endlich diesen Block auch löschen zu können. Würde man hier nicht für Ordnung sorgen, wäre die Platte vermutlich innerhalb kürzester Zeit unbrauchbar. Es kommt aber noch eine weitere unangenehme Eigenschaft der NAND Zellen hinzu, dass diese erst bzw. nur dann beschrieben werden können, wenn sie explizit leer sind. Anders wie bei herkömmlichen Festplatten, wo einfach die magnetische Ausrichtung geändert wird, sobald ein als gelöscht markierter Bereich neu beschrieben wird, muss bei SSD Festplatten dafür gesorgt werden, dass als gelöscht markierte Bereiche auch explizit gelöscht werden, bevor sie erneut beschrieben werden können.

Aber es gibt Gegenmaßnahmen, welche den drohenden Einbruch der I/O Performance verhindern sollen. Diese sind zT ein streng gehütetes Geheimnis der Festplattenhersteller und somit von unterschiedlicher Güte und Qualität. Wenn wir uns nochmal vor Augen führen, dass auf die SSD Platte in 4KB Pages geschrieben wird aber in 512KB Blöcken gelöscht wird und wir jetzt zB eine 8KB große Datei in zwei Pages auf einer SSD Platte speichern und später wieder löschen, werden diese solange nicht wirklich gelöscht, solange nicht ein bestimmter Pronzentsatz eines Blocks mit gelöscht markierten Pages erreicht ist. Dadurch wird verhindert, dass einzelne Block außerordentlich stark frequentiert werden, wogegen andere Bereiche der SSD kaum oder gar nicht benutzt werden. Dadurch wird die SSD zwar recht gleichmäßig ausgelastet, jedoch kommt man ziemlich schnell an den Punkt, wo die eigentlichen 512KB Blöcke zum größten Teil in Verwendung sind, diese jedoch nur zu einem Teil aus noch gültigen Daten und zum anderen Teil aus nicht mehr gültigen Daten bestehen.

Jetzt geht das große Geschiebe und Sortieren los, was sich »Garbage Collection« nennt und in den Einzelheiten ein gut gehütetes Betriebsgeheimnis der einzelnen Hersteller ist. Man stelle sich nun einen Block 1 bestehend aus 12 imaginären Pages vor (eigentlich sind es 128 Pages) und wir speichern eine Datei A mit 16KB ab, so werden vier Pages (1 bis 4) a 4KB im Block 1 verwendet. Speichern wir jetzt noch eine Datei B mit 16 KB ab, werden die Pages 5 bis 8 im Block 1 belegt. Löschen wir Datei A, werden die vier Blöcke 1 bis 4 nur als gelöscht markiert, sind aber noch nicht zum erneuten Beschreiben bereit (Wir erinnern uns, NAND Zellen können nur beschrieben werden, wenn sie explizit leer sind). Wenn jetzt noch eine 16KB Datei gespeichert wird, belegt sie die Pages 9 bis 12 und der Block 1 ist somit vollständig ausgelastet. Um nun die Pages 1 bis 4 wieder für ein erneutes Beschreiben verfügbar zu machen, müssen die Pages 5 bis 12, welche noch gültige Daten beinhalten, in einen neuen, leeren Block 2 verschoben werden, damit der erste Block 1 vollständig gelöscht und somit wieder zum Beschreiben von Daten freigegeben werden kann.

Das Problem bei der ganzen Angelegenheit ist aber, dass die Festplatte selbst nicht weiß, welche Pages bereits als gelöscht markiert sind und verschiebt diese uU bei der Blockoptimierung mit. Der Festplattencontroller erkennt erst dann, dass eine Page ungültig geworden ist, wenn er die Aufforderung bekommt eine bestimmte LBA (numerische Positionsangabe eines Sektors bzw. einer Page) zu überschreiben. Nun würde aber die oben bereits erwähnte Garbage Collection die Performance der SSD dramatisch senken, wenn dieses Erkennen der noch gültigen Pages eines Blocks, das Verschieben selbiger in einen leeren Block und das Löschen des gesamten Blocks in dem sich die angewiesene LBA befindet, sofort ausgeführt würde. Daher wird der Festplattencontroller die Datei in einem der vorhandenen und leeren Reserveblöcke umleiten und da er nun Kenntnis darüber bekommt, welche Pages als gelöscht markiert sind, wird er diese bei der Garbage Collection auch als solche erkennen und nicht unnötigerweise mit den gültigen Pages verschieben, sondern bei diesem Vorgang auch gleich löschen. Durch mehr oder weniger intelligente Algorithmen wird dadurch auch eine Defragmentierung und intelligente Anordnung der verwendeten Blöcke, Pages und freien Speicherbereiche erreicht.

In diese Kerbe springt nun das neue ATA-TRIM Kommando, welches von einem Betriebssystem, welches diese Funktion unterstützt, beim Löschen einer Datei die Information gleich an den Festplattencontroller weitergibt (welcher diese Funktion ebenfalls unterstützen muss). Somit weiß der Controller wesentlich früher, welche Pages in seinem System keine Gültigkeit mehr haben und kann somit seine internen Garbage Collection optimieren und muss nicht warten, bis er die Anweisung vom Betriebssystem, respektive vom Dateisystem bekommt, eine Datei an einer bestimmte Stelle zu speichern, welche eigentlich noch gar nicht dafür vorbereitet ist.