Narf – da war der Bug schneller als der Admin hinter dem Monitoring: 0k freier Speicher vermeldet ein ZFS-Storage. Na kein Problem, kaputtes Programm gestoppt und schnell mal den Schrott gelöscht. Oder auch nicht:

rm: cannot remove file: Disk quota exceeded

Really?!

Ursache wäre wohl „COW“ – Copy on write. Bei Änderungen werden die neuen Daten erst mal auf die Festplatte geschrieben – erst wenn dort kein Fehler auftritt werden die entsprechenden Zeiger im Dateisystem aktualisiert und die vorherigen Daten ungültig.

Die Lösung, welche z.B. bei der Uni Freiburg zu finden ist, ist effektiv, aber mir nicht wirklich verständlich: Anstatt die Datei zu löschen wird sie erst mit /dev/null überschrieben – dies schlägt trotz COW offenbar nicht fehl. Der so freigewordene Speicherplatz, welche zuvor durch den Inhalt der Datei belegt wurde, sollte nun ausreichen um den Löschbefehl umzusetzen:

rm test
#rm: cannot remove file `test': Disk quota exceeded
cp /dev/null test
rm test
stat test
stat: der Aufruf von stat fuer "test" ist nicht moeglich: Datei oder Verzeichnis nicht gefunden

Das Scrubbing ist ein wichtiger Part der regelmäßigen Pflege eines ZFS-Systems. Hierbei liest das System alle belegten Dateisystemblöcke, vergleicht den Inhalt mit der hinterlegten Prüfsumme und korrigiert – wenn nötig – Fehler auf dem Speicher. Hierdurch ist sichergestellt, dass kippende Bits auf den Festplatten nicht den Inhalt der Datei beschädigen und Fehler frühzeitig erkannt werden. Ein Scrub wird hierbei über den Befehl „zpool scrub poolname“ gestartet.

Um Wöchentlich ein Scrubbing aller zpools durchzuführen nutze ich etwas Bash-Magie – das folgende Script erstellt eine Liste aller im System bekannten zpools und führt ein scrubbing dieser durch. Da ich zum Teil mehrere zpools auf Partitionen einer Platte habe wird immer nur ein Scrub simultan durchgeführt, so wird das Storage nicht zu stark belastet.

#!/bin/bash
date
for i in `zpool list | cut -d ' ' -f 1 | tail -n +2` ;do
    echo $i
    zpool scrub $i

    #Voodoo to prevent simultanous scrubs
    while (zpool status audio | grep scan: | grep scrub > /dev/null) ;do
        sleep 60
        #Scrub still running
    done
done
date

Aber auch ein einzelner Scrub stellt für das System eine nicht unerhebliche Last dar, welche sich negativ bemerkbar machen kann. In meinem Fall ist es eine Datenbank mit vielen kleinen Schreiboperationen, welche während des Scrubs nicht hinzunehmende Delays aufweist. Um hier Abhilfe zu schaffen kann ZFS eine Pause einlegen, sobald IO-Aktivität auf dem Pool entdeckt wird. Kontrolliert wird dieser Wert unter Linux mit dem Parameter /sys/module/zfs/parameters/zfs_scrub_delay – dieser ist per Default auf 4 eingestellt. Die Angabe bezieht sich hierbei laut Dokumentation auf Systemticks, bei den meisten Desktop-PCs ist Tickrate von 1000Hz, bei Server meist 100Hz, üblich. Um zu Prüfen wie das eigene System eingestellt ist kann meist folgender Einzeiler verwendet werden:

zcat /proc/config.gz | grep -E "^CONFIG_HZ_.*=y$"
CONFIG_HZ_250=y

Wie zu sehen ist läuft mein System auf 250Hz. Zusammen mit der Angabe oben würde ZFS bei IO also für 16ms (1s/250Hz*4) pausieren. Um mir etwas Zeit zu verschaffen möchte ich diesen Wert auf 250ms erhöhen:

1 Sekunde / 250Hz = 0,004 Sekunden/Tick = 4 Millisekunden/Tick
250 Millisekunden / 4 Millisekunden ~= 63 Ticks

Dieser Wert wird entsprechend dem Parameter zugewiesen.

echo 63 > /sys/module/zfs/parameters/zfs_scrub_delay

Wirklich messbar ist der Unterschied nur schwer, da er sich nur bei kleinen, zeitlich verteilten Operationen und nicht bei den benchmarküblichen und konstanten Sequential und Random-Operationen bemerkbar macht, gefühlt ist die Reaktion jedoch trotz scrub besser geworden.

Natürlich sollte man bedenken, dass der Scrub entsprechend länger dauert, die Werte sollten also nur temporär oder mit viel Vorsicht geändert werden.