Zerstörung

Das Kommando »flashcache_destroy« zerstört einen Cache samt all seinen Daten. Ein Entfernen eines Cache-Volumes erfolgt direkt über den DM-Befehl »dmsetup remove« . Der Remove-Aufruf kehrt für ein Write-Back-Volume erst dann zurück, wenn alle Dirty Pages auf die HDD geschrieben sind. Dieses Blockieren garantiert ein sauberes Aushängen des Volumes, das via Load-Befehl später wieder geladen werden kann ( Abbildung 2 ).

Abbildung 2: Schematischer Ablauf der Verwaltung eines Cache-Volumes.

Für die Überwachung der Cache-Funktion stellt Flashcache mehrere Statistiken bereit, die sich mit »dmsetup status« und »dmsetup table« anzeigen lassen. Der Status-Befehl zeigt vor allem die Lese-und Schreibstatistiken. Wichtig hierbei sind zum Beispiel die Angaben zu den Treffern im Cache ( »read hit« und »write hit percent« ) oder Lese- und Schreiboperationen auf SSD und HDD ( »disk/ssd reads« und »writes« ).

»dmsetup table« beinhaltet dazu noch einige Konfigurations-Informationen des Volumes ( Listing 2 ). Von Interesse ist auch das Größen-Histogramm der abgesetzten I/O-Operationen (Size Hist). Flashcache cacht immer nur Blockzugriffe, die gleich oder ein Vielfaches der Blockgröße des Caches sind (Standardgröße 4 KByte). Eine steigende Anzahl an 512-Byte-I/Os signalisiert, dass Zugriffe einer Applikation nicht gecacht werden. Vorsicht ist somit auch bei Flashcache-Performance-Tests mit dem beliebten Werkzeug »dd« geboten, da es standardmäßig mit 512 Byte als Block-Größe arbeitet.

Tuning

Ein Flashcache-Volume bietet zahlreiche Konfigurationsmöglichkeiten über »sysctl« an. Diese Kontroll-Optionen eignen sich nicht nur zum Anpassen eines Flashcache-Volumes an die eigenen Bedürfnisse, sondern geben auch nützliche Informationen über die interne Funktionsweise. Der folgende Abschnitt zeigt einige Repräsentanten der Optionen:

Der Sysctl »cache_all« erlaubt es, das Caching ein- und auszuschalten. Auf Black- und Whitelisting von Prozess-IDs hat diese Option großen Einfluss (siehe unten). Auch wenn kurzzeitig Test- oder temporäre Daten nicht im Cache landen dürfen, ist es sinnvoll, den Cache zu deaktivieren, um die SSD nicht mit nicht benötigten Daten zu füllen.

Basierend auf der Storage-Architektur hinter der SSD, gibt es Szenarien, bei denen sich ein SSD-Cache negativ auf die Performance auswirkt. Wird die SSD als Cache für ein RAID-Array genutzt, dessen Durchsatz für sequenzielle Zugriffe größer ist als jener der SSD, macht sich der Cache negativ bemerkbar. Das betrifft Schreib- und Leseoperationen gleichermaßen. Beim Schreiben ist der Einfluss der SSD-Schreibgeschwindigkeit offensichtlich, beim ungecachten Lesen erschließt er sich erst auf den zweiten Blick: Werden Daten gelesen, die sich nicht im SSD-Cache befinden, ist die Lese-Operation erst dann abgeschlossen, wenn der angeforderte Bereich vom RAID gelesen, in den SSD-Cache geschrieben und schließlich an die Applikation weitergegeben wurde [5] .

Die SSD-Schreib-Performance ist deshalb ein wesentlicher Faktor für die Performance-Verbesserung. Für sequenzielle Zugriffe existiert mit »skip_seq_thresh_kb« ein Schwellwert, über den sich die SSD-Defizite etwas ausgleichen lassen. Weist man ihm zum Beispiel den Wert 1024 zu (standardmäßig 0), landen alle sequenziellen I/Os über 1024 Kilobyte nicht mehr im Cache. Die niedrigere Performance der SSD für sequenzielle Zugriffe wird dadurch eliminiert.