[ZFS/Linux] Priorisierung und Systemlast durch Scrubbing kontrollieren

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.

BitBastelei #130 – Acer P191w Monitor-Reparatur

BitBastelei #130 - Acer P191w Monitor-Reparatur

(85 MB) 00:14:15

2015-01-04 11:00 🛈

Während ich für den großen Fernseher noch auf Ersatzteile warte ist ein anderer Patient eingetroffen: Ein Acer P191w, welcher „nicht mehr an geht“. Nunja, vielleicht habe ich hier ja mehr Glück und bekomme ihn schneller ans Laufen.

Das xrandr-Voodoo gegen Ende lässt sich hier nachlesen.

BitNotice #76 – Mailbag: Waage

BitNotice #76 - Mailbag: Waage

(47 MB) 00:07:24

2015-01-01 12:56 🛈

…eigentlich will ich’s ja gar nicht wissen, aber wenn so eine Personenwaage im üblichen Onlineauktionshaus für unter 5€ incl. Porto vor der Nase steht kann man den Messgerätepark ja mal vergrößern. Fragt sich nur: Was kann man für den Preis erwarten?

Interfacebasiertes OpenVPN-Routing und martian packets

Ab und an sehen meine Wünsche recht speziell aus, ich weiß. Heut sieht die Aufgbe wie folgt aus:

Ein Router besitzt 3 Netzwerkkarten, eth0 ist direkt an das Internet angeschlossen, eth1 versogt das Netzwerk A und eth2 das Netzwerk B. Zusätzlich gibt es über OpenVPN (tap0) einen Link zu einem externen Internetzugang. Ziel ist nun, dass alle Internetanfragen von Netzwerk B (eth2) über das VPN versendet werden, der Rest jedoch nicht.

Der (zusammenkopierte) Entwurf lautete wie folgt:

iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-xmark 0x1/0xffffffff
-> Alles was aus Netzwerk B kommt wird mit Flag 0x1 versehen

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
-> Alles was über tap0 raus geht wird per NAT maskiert

ip route add unreachable default table 42
-> Alles auf der Routingtabelle 42 wird per default abgelehnt

ip rule add from all fwmark 0x1 table 42
-> Alles mit der Markierung 0x1 gehört zur Tabelle 42

ip route replace 0.0.0.0/1 via *OpenVPN-IP* table 42
ip route replace 128.0.0.0/1 via *OpenVPN-IP* table 42
-> Alles auf Tabelle 42 wird über den VPN-Server abgewickelt

net.ipv4.ip_forward ist auf 1

Auf den ersten Blick ist auch alles OK, Netzwerk A und der Server funktionieren fehlerfrei. Vom Netzwerk B ist jedoch kein Internetzugriff möglich. Getreu dem guten alten Troubleshooting-Guide also auf die Suche.

Wenn ich von einem Client in Netzwerk B pinge kommt das Paket am Router auf eth2 an:

[eth2] 10.222.100.53 > 8.8.8.8: ICMP echo request

…und wird auf tap0 nach draußen gesendet:

[tap0] 10.8.0.16 > 8.8.8.8: ICMP echo request

Kurz drauf trifft auch von draußen über das VPN eine Antwort ein:

[tap0] 8.8.8.8 > 10.8.0.16: ICMP echo reply

und dann hing es… Die Antwort wird nicht auf eth2 wieder weitergegeben, dort ist kein Traffic erkennbar. Scheint, als ob irgendwas beim NAT schief geht. Wenn ich logging auf Maximum stelle (net.ipv4.conf.tap0.log_martians=1) ist im syslog folgendes zu lesen:

kernel: IPv4: martian source 10.222.100.53 from 8.8.8.8, on dev tap0

Ich vermute, dass hier das NAT durch die verschiedenen Routing-Tabellen ein zu großes Chaos verursacht. Als „Workarround“ ist auf dem VPN-Interface jetzt Source-Filterung ausgeschaltet (net.ipv4.conf.tap0.rp_filter=0). Da die Gegenseite ohnehin nochmals nattet sollte da nichts böses(™) drüber eintrudeln.

Sollte jemand genauer erklären können was hier passiert freue ich mich über einen Kommentar.

BitBastelei #129 – Dancing USB Robot

BitBastelei #129 - Dancing USB Robot

(44 MB) 00:20:19

2014-12-28 11:00 🛈

Spielzeug… Zu Weihnachten gab es einen tanzenden USB-Roboter der Firma „Dream Cheeky“. Windows only versteht sich. Ohne weitere Ahnung wird also „mal schnell“ ein Linux-Tool zur Ansteuerung improvisiert.

https://github.com/adlerweb/ctlrobot

Xrandr: Manuelle Wahl der Auflösung

Xrandr ist auf Laptops und 1-GPU-Setups die einfachste und zuverlässigste Methode zur Steuerung der Bildausgabe. Monitorposition, Auflösung, Drehung – alles lässt sich über die Konsole oder die zahlreichen GUIs steuern – wenn die Hardware mitmacht. Für wenig Geld habe ich vor kurzem einen Acer P191w (Video folgt) in die Finger bekommen, dieser sollte nun „mal kurz“ mein Netbook-Display erweitern. Eigentlich kein Problem: Anklemmen, einschalten, fertig. Leider scheint die DCC-Info des Monitors, welche dem Rechner u.A. die möglichen Auflösungen mitteilt, fehlerhaft und es zeigt sich dieses Bild:

> xrandr
Screen 0: minimum 8 x 8, current 1824 x 600, maximum 32767 x 32767
LVDS1 connected 1024x600+800+0 (normal left inverted right x axis y axis) 190mm x 110mm
1024x600 60.00*+
800x600 60.32 56.25
640x480 59.94
VGA1 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.00
800x600 60.32* 56.25
848x480 60.00
640x480 59.94
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Wie man im mittleren Bereich sieht ist die maximal wählbare Auflösung 1024×768 Pixel. Laut Datenblatt sollte das Panel nativ mit 1440×900 Pixeln arbeiten, entsprechend verzerrt und unscharf sieht auch das Bild aus.

Mit ein paar Befehlen kann man xrandr die nicht erkannte Auflösung beibringen. Hierzu benötigen wir erst mal eine Modeline – diese lässt sich mit dem Tool „cvt“ berechnen. Hier für 1440×900 Pixel bei 60Hz:

> cvt 1440 900 60
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync

Diese Info muss man nun in xrandr bekannt machen und dem Monitor zuweisen:

> xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
> xrandr --addmode VGA1 "1440x900_60.00"

Im Anschluss sollte sich die Auflösung mit dem Tool der Wahl einstellen lassen, auf der Konsole also wie folgt:

xrandr --output VGA1 --auto --mode 1440x900_60.00 --left-of LVDS1

Schon kann auch dieser Monitor mit seiner korrekten Auflösung arbeiten und in den nächsten Tagen mir diverse Metadaten des 31c3 anzeigen.

BitBastelei #128 – Philips 37PFL8404H Reparatur – Part 2

BitBastelei #128 - Philips 37PFL8404H Reparatur - Part 2

(193 MB) 00:24:42

2014-12-21 11:00 🛈

There, i fixed it… Oder auch nicht… Oder ich mach einfach alles kaputt…

BitNotice #75 – Mailbag: Google Cardboard Klon

BitNotice #75 - Mailbag: Google Cardboard Klon

(43 MB) 00:06:29

2014-12-20 12:14 🛈

Google Cardboard – etwas Pappe, zwei Plastiklinsen und ein Magnet. Was wie die Überreste der Bastelkiste klingt kann ein Handy in eine einfache VR-Brille verwandeln.

https://www.google.com/get/cardboard/

Bestellt: http://www.dx.com/p/339632?Utm_rid=30187698&Utm_source=affiliate

Geliefert: http://www.dx.com/p/357235?Utm_rid=30187698&Utm_source=affiliate

BitNotice #74 – Multimedia unter Linux – Musikverwaltung

BitNotice #74 - Multimedia unter Linux - Musikverwaltung

(15 MB) 00:08:02

2014-12-17 09:00 🛈

Gegen Ende der Serie entfernen wir uns vom Erstellen von Multimediainhalten und werfen nochmals einen Blick auf Sortieren und Abspielen – diesmal geht es dabei um die Verwaltung der heimischen Musiksammlung

Banshee
Rhythmbox
Amarok
Clementine

Musik:
Alex S. – Ultimate Sweetie Belle
Ken Ashcorp – 20 Percent Cooler

Nerd Inside