Cache-Persistenz

Zurzeit bleibt nur beim Write-Back-Modus der Cache-Inhalt über einen Reboot hinweg erhalten (persistenter Cache). Dies resultiert daraus, dass Flashcache nur für Write-Back Cache-Metadaten auf der SSD verwaltet. Für die anderen beiden Modi betreibt es diesen Aufwand zur Zeit noch nicht. Dieses Fehlen der Metadaten hat nicht nur Nachteile: Für Dirty Pages müssen bei einem Write und Clean immer auch die Metadaten geschrieben werden. Um nicht jedes Mal für jeden Block die Metadaten aktualisieren zu müssen, gibt es ein Batching für mehrere verschiedene Metadaten-Blöcke und für sequenzielle Updates desselben Blocks.

Bei einem Reboot oder Shutdown des Hosts werden im Falle von Write-Back alle Dirty Pages von der SSD auf die HDD synchronisiert – das lässt sich manuell auch über »dmsetup remove« erreichen (siehe unten). Dagegen entfernt »sysctl (fast_remove)« den Cache ohne Synchronisation. Diese Option birgt immer ein gewisses Risiko, da sich Daten im Cache befinden, die noch nicht auf der Festplatte gelandet sind.

Metadaten werden beim kontrollierten Entfernen für alle Cache-Blöcke auf die SSD geschrieben, bei einem Node-Crash hingegen bleiben nur die Dirty-Blöcke im Cache erhalten. Für Write-Through und Write-Around bedeutet ein Remove beziehungsweise Neustart des Hosts einen Verlust des Caches. Nichtsdestotrotz kann für alle drei Fälle ein sauberes Entfernen des Caches sinnvoll sein, zum Beispiel, wenn das Flashcache-Modul neu kompiliert und geladen werden muss.

Volume-Verwaltung

Flashcache bringt drei Kommandozeilen-Werkzeuge für die Administration von Cache-Volumes mit: »flashcache_create« , »flashcache_load« und »flashcache_destroy« . Die Zugehörigkeit zum Device Mapper (DM) ist der Grund dafür, dass Cache-Volumes auch via »dmsetup« verwaltet werden könnten. Die Flashcache-Tools erleichtern aber wesentlich den Umgang, und nur selten wird der Weg direkt über den DM nötig sein.

Beim Anlegen eines Caching Volumes mit »flashcache_create« sind vor allem der Caching-Modus ( »-p« ), die Cache-Größe, die Block-Größe, ein Volume-Name sowie die Pfade zur SSD und HDD wichtig. Wird die Cache-Size ( »-s« ) nicht angegeben, verwendet Flashcache die gesamte SSD als Cache-Device für das Volume. Ohne Angabe einer Block-Größe ( »-b« ) kommt die Standardgröße von 4 KByte zum Einsatz. Listing 1 erstellt ein Write-Back-Cache namens »fc-root« mit »/dev/sdd« als SSD und »/dev/sdc« als HDD .

Nach dem Aufruf von »flashcache_create« erscheint das Volume unter dem Pfad »/dev/mapper/fc-root« . Daraufhin kann man ein Ext4-Filesystem anlegen und das Volume eingehängen.

Wer sich wundert, warum der Cache nach dem Mount bereits gecachte Blöcke enthält, sei auf die Lazy Initialization von Ext4 verwiesen. Der Kernel-Prozess »ext4lazyinit« initialisiert zu Beginn die Inode Tables des Filesystems. Ist dies nicht gewünscht, müssen »mkfs.ext4« mit der Option »-E« die Parameter »lazy_itable_init=0,lazy_journal_init=0« übergeben werden [4] .

Einmal erstellte Flashcache-Volumes lassen sich mit frm Befehl »flashcache_load« wieder laden. Der Load-Befehl kann nur für Write-Back-Volumes verwendet werden, da dies die einzige persistente Variante ist. Für Write-Through und Write-Around muss man nach jedem Remove wieder einen neuen Cache erstellen.