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
).
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.
Listing 2
Status-Überblick über das Volume
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.