Einschlafprobleme der Festplatte

Nachträgliches Vorwort

Diese Seite berichtet von den Einschlafproblemen der Magnetfestplatte, die ich zunächst als einzige externe Festplatte vorgesehen hatte. Nachdem ich im Freundes- und Bekanntenkreis häufiger von meinen Beobachtungen erzählt habe, wurde mir immer häufiger die Verwendung einer SSD vorgeschlagen (Grüße gehen an Marco und Markus). Anfangs war ich skeptisch, weil ich von höherem Stromverbrauch und Temperaturproblemen gehört hatte, aber nach ersten Experimenten war ich schnell überzeugt. Auch bei der SSD habe ich eine Art Einschlafvorgang beobachtet, vermutlich irgendein Cache- oder Wear-Leveling-Ding, oder ein Standby der Kontroll-Logik. Dieser lag jedoch größenordnungsmäßig bei wenigen Minuten und hat auch insgesamt nicht so viel am Stromverbrauch geändert.

Update: nach rund einem halben Jahr Betrieb mit der SSD als Haupt-Datenträger und der Magnetfestplatte als Backup habe ich das Überwachungsskript komplett eingemottet und mit Version 1.1 entfernt. Diese Erweiterung war eine der besten Entscheidungen überhaupt und absolute empfehlenswert.

Die Beobachtung

Zu Beginn hatte ich einen USB-Stick als Massendatenspeicher benutzt, weil die eigentlich dafür vorgesehene USB-Festplatte noch direkt am PC hing und erst als letzter Schritt der Inbetriebnahme umgehängt werden sollte. Während der Untersuchung der Probleme mit der Systemstabilität kam ich an einen Punkt, an dem ich die Swap-Datei auf die echte Festplatte legen wollte und dementsprechend den Massendatenspeicher gewechselt habe. Dabei habe ich dann die Beobachtung gemacht, dass die Festplatte nicht einschläft, sondern durchgängig rotiert. Verschiedenen Einschätzungen zufolge hat dies zwar keine relevante Auswirkung auf die Lebenserwartung, wohl aber auf den Stromverbrauch, der bei einem 24/7 laufendem Gerät durchaus relevant ist.

Wenn keine Dienste laufen, dann schaltet die Festplatte von sich aus nach 30 Minuten in den Schlafmodus. Wenn alles läuft was da ist, dann schaltet sie niemals ab. Also muss es irgendwie mit den Diensten zusammenhängen -- sei es direkt (Lese-/Schreibzugriffe der Anwendungen) oder indirekt (z.B. über die Swap-Datei).

Ein Schuldiger wird gesucht

Im Rahmen der Untersuchung zur Systemstabilität hatte ich bereits verschiedene Kombinationen aus den unterschiedlichen Diensten durchprobiert und das jeweilige Verhalten protokolliert. Aufzeichnungen sind dabei extrem wichtig, um später Zusammenhänge erkennen zu können, ohne sich in Bauchgefühl und vorschnellen Schlüssen zu verlieren. Ich konnte also im gleichen Stil weiter machen, mit der kleinen Schwierigkeit, dass sich das Verhalten nur direkt beobachten ließ. Das war aber nicht schlimm, ich hatte den Aufbau am Schreibtisch stehen und habe an einem Arbeitstag im Homeoffice gut mitbekommen, wenn die Festplatte ihre Powerdown-Zeremonie durchlief (sehr auffälliges Geklacker und dann auf einmal ein Gefühl, als hätte man Watte im Ohr, weil ein Hintergrundgeräusch weg ist).

Erste Auswertung, mit Swap-Datei auf der Festplatte:

Vaultwarden hatte ich gar nicht drin, weil das erste Muster das Ende einer vorherigen Versuchsreihe war, während der ich vom USB-Stick auf die Festplatte gewechselt und somit das Problem überhaupt erst bemerkt hatte. Da alle Dienste außer Vaultwarden bereits die Platte wach hielten war es recht unnötig, Vaultwarden auch noch mit reinzunehmen. Die wichtige Erkenntnis hier war: Dienste, die einzeln kein Problem verursachen, können in Kombination doch problematisch sein (Filebrowser, Linkding). Zweite Erkenntnis: das Vorhandensein einer Swap-Datei ist an sich kein Problem, allerdings hängt dies vom Nutzungsverhalten ab.

Als nächstes habe ich zur Gegenprobe die Swap-Datei wieder auf den USB-Stick gelegt, aber die Applikationsdaten auf der Festplatte belassen. Könnte ja auch sein, dass die Dienste an sich die Platte nageln...

Der letzte Versuch diente zur Kontrolle und lief längere Zeit um sicher zu sein, dass die Festplatte tatsächlich reproduzierbar einschläft (was sie tat). Das Fazit: sowohl Meemo als auch Valtwarden halten für sich genommen die Festplatte wach. Zwei Schuldige also.

Was Vaultwarden und Meemo so treiben

Jetzt galt es herauszufinden, warum Vaultwarden und Meemo die Platte wach halten und ob sich etwas daran ändern lässt. Ich habe dazu mit find und den Parametern -amin, -cmin und -mmin alle paar Minuten die Dateien ausgeben lassen, deren atime (access, Inhalt wurde gelesen), ctime (change, Metadaten wurden geändert) oder mtime (modified, Inhalt wurde geändert) jünger als 5 Minuten war.

Für Vaultwarden fiel der Verdacht sehr schnell auf db.sqlite3-wal, dem Write-Ahead Logging der SQLite-Datenbank. Etwas weitere Recherche führte dann zu einem Forenbeitrag mit einem ähnlichen Anwendungsfall, zu dem es allerdings keine abschließende Klärung gab. Also habe ich weiter gesucht und, inzwischen mit den richtigen Suchbegriffen bewaffnet, diesen Artikel im Vaultwarden-Wiki gefunden, der beschreibt wie man das WAL abstellen kann. Das hat für mich das Problem behoben (was ich dann auch im Forenbeitrag für die Nachwelt ergänzt habe).

Etwas fruchtloser war das Unterfangen bei Meemo. Dort war es die MongoDB, die gnadenlos alle paar Sekunden (nicht wenig) Diagnosedaten rausgehauen hat. Da Meemo nach den Stabilitätsproblemen und dem irren Speicherverbrauch ohnehin schon auf meiner Abschussliste stand habe ich beschlossen, auf diesen Dienst zu verzichten. Alternativ hätte man evtl. die Erhebung der Diagnosedaten abstellen können, aber vermutlich nur durch Änderungen am Container-Image und das Fass wollte ich nicht aufmachen.

Ist es jetzt weg?

Bisher hatte ich nur gesehen, was die Festplatte vom Einschlafen abhält. Dabei war ein Setup für mich unschuldig, wenn ich die Festplatte einschlafen gesehen habe. Ob die Festplatte dann allerdings auch dauerhaft schläft ist damit nicht bewiesen und auch nicht selbstverständlich. Ein erster Langzeitversuch hat auch prompt gezeigt: die Festplatte wird im neu favorisierten Setup (alles außer Meemo) immer noch sporadisch wach. Voll doof. ;-)

Eine Analyse der Container-Images hat diverse Cron-Jobs zu Tage gefördert, die möglicherweise die Ursache sein könnten. Aber ob Analyse und gezielte Änderung oder weiteres systematisches Ausprobieren: um sagen zu können, dass das Problem nicht mehr auftritt, muss das System eine Zeit lang beobachtet werden. Mit dem Aufhängen war das leicht: ein Auftreten führt zu einem stabilen Zustand, den man später vorfindet. Aber wer merkt, ob die Festplatte mitten in der Nacht anspringt? Ich, aber nur zufällig, um 1:00 Uhr, als ich von einer Feier heimkam. Zufall ist Mist bei systematischer Suche. Also musste ein Weg zur zuverlässigen Erkennung der Festplattenaktivität her.

Sowohl hdparm als auch smartctl konnten bei meiner Festplatte nicht erkennen, ob sie wach ist oder schläft, obwohl dies grundsätzlich funktionieren sollte. Auch den Stromverbrauch beim USB-Host abzufragen hat nicht geholfen, die angepriesene Methode gibt nur das an, was das Gerät angefordert hat, und das war in jedem Betriebszustand das Maximum von 500 mA. Blieb also noch die Möglichkeit, die Festplatte selbst zu beobachten, also außerhalb des Raspberry Pis:

• Die Status-LED ist im Wachzustand an bzw. flackert bei Zugriffen; im Standby blinkt sie gemütlich; das Signal irgendwie abgreifen?
• Der Motor ist im Wachzustand an und im Standby aus; die Vibration bzw. das Geräusch detektieren?
• Der Stromverbrauch ist sehr wahrscheinlich unterschiedlich; via Induktion, Hall-Effekt oder per Zwischenstecker messen?

Ich habe mich für die optische Beobachtung der Status-LED entschieden, da dies am wenigsten invasiv erschien (Festplatte muss nicht geöffnet werden) und ich auch die wenigsten Störungen von Außen erwartet habe bzw. diese leicht abzuschirmen sein sollten (Pappkarton).

Der erste Versuchsaufbau

Mein erster Aufbau erscheint im Rückblick ... sagen wir übermäßig optimistisch. Ich habe einen beliebigen Fotowiderstand (LDR, Light Dependent Resistor) aus der Bastelkiste gegriffen (um genau zu sein: den einzigen den ich finden konnte) und mal nach Gefühl mit einem 10k-Widerstand einen Spannungsteiler aufgebaut (LDR nach GND). Dann das ganze so positioniert, dass die LED einen schönen Lichtpunkt auf die LDR-Fläche geworfen hat und ausprobiert, was der Pi sieht. Dabei habe ich die erste Lektion gelernt: auch wenn die Multifunktionsleiste einen +5V-Pin hat bedeutet das nicht, dass die Eingänge für 5 Volt geeignet sind. Zum Glück ist nichts kaputt gegangen, aber Vorsicht: die GPIOs des Raspberry Pi vertragen maximal +3,3 Volt.

Eigentlich wollte ich die GPIOs per Perl auslesen, aber irgendwie konnte ich kein funktionierendes Paket finden. Im Raspbian-Repository war nichts und das CPAN-Paket hat nicht ordentlich gebaut. Nach kurzer Recherche hatte ich mich daraufhin für das Kommandozeilen-Tool pigs entschieden. Dazu startet man zuerst den Dienst pigpiod, der mit der eigentlichen Hardware spricht. Das Programm pigs kommuniziert dann mit dem Dienst via Socket-Schnittstelle. Um den Logik-Level des GPIO-Pins zu ermitteln ruft man z.B. pigs r 14 auf und erhält "0" oder "1". Das ganze habe ich anschließend in mein Perl-Skript gewickelt und herumexperimentiert.

Kurze Zeit darauf habe ich dem Aufbau noch einen Deckel aus Pappe spendiert, um Streulicht fernzuhalten, und weil der auf den LDR gedrückt hatte und nur noch 1en kamen (der Logik-Level ist bei diesem Aufbau invertiert) hatte ich das Steckbrett noch etwas aufgebockt. Das Ergebnis war dennoch etwas enttäuschend, denn obwohl es auf dem Schrank deutlich dunkler war, als das Blitzlicht auf den Fotos erscheinen lässt, habe ich viele zufällige Werte erhalten und war irgendwie permanent am Nachjustieren des Lichtpunkts. Nach ein paar Stunden war dann klar: weg mit dem Mist und noch mal ordentlich entwickeln.

Der zweite Versuchsaufbau

Im zweiten Anlauf habe ich gleich auf bekannte, in größerer Stückzahl vorhandene Bauteile gesetzt und habe ein 10er-Päckchen "GL5549" gekauft (eBay, 2,69 EUR inkl. Versand als Brief). Diese haben im Dunkeln einen Widerstand von 10M und bei 10 Lux Beleuchtung nur noch ca. 100k. Ich hatte keine Ahnung wie viel 10 Lux sind, aber dachte mir, dass es schon passen wird. Außerdem habe ich einen stabileren Aufbau aus Holz gebaut, damit ich reproduzierbare Ergebnisse bekomme. Ich wollte die Festplatte nicht komplett einhausen, weil ich nicht weiß wie warm sie im Betrieb wird, und ich vom Pi selbst schon etwas traumatisiert war, was Probleme mit der Abwärme angeht. Heraus kam diese Konstruktion:

Die Modellbauleisten sind etwas höher als die Festplatte, wodurch ein Spalt entsteht, durch den Licht von hinten einfallen kann. Diesen habe ich mit etwas schwarzem Filz zugestopft um noch bessere Ergebnisse zu erhalten (tatsächlich hatte ich tagsüber zwischen 14:00 und 16:00 Uhr gelegentliche False Positives, weil der LDR eine dauerhaft eingeschaltete LED vermutet hatte). Der LDR sitzt auf dem Sperrholzplättchen der LED direkt gegenüber, quasi Auge in Auge.

Bei ausgeschalteter LED habe ich einen Widerstand von ca. 1,8 Megaohm gemessen, mit zugestopften Ritzen sogar >2M (weiter misst mein Multimeter nicht). Bei leuchtender LED fällt der Wert auf rund 350 Kiloohm. Leider sind keine zuverlässigen Werte für die Schwellen bekannt, bei denen der Raspberry Pi einen Pin als High oder Low erkennt, aber diverse Forenbeiträge lassen vermuten, dass <0,9V für Low und >1,6V für High eine sichere Sache sind. Ich habe zwei mögliche Spannungsteiler ausgerechnet, jeweils mit den sich daraus ergebenden minimalen und maximalen Widerstandswerten für den LDR:

Man sieht, dass da noch einiges an Reserve drin steckt. Ich habe mich für einen Wert von 470k entschieden (nicht auf dem Foto zu sehen; dort ist noch ein viel größerer Wert verbaut). Außerdem habe ich eine LED mit Vorwiderstand an einem anderen GPIO hängen, um den tatsächlich von der Software erkannten Wert wiederzugeben. Das hat ernorm geholfen um den Tag über immer mal wieder prüfen zu können, ob alles stimmt (so hatte ich die False Positives am Nachmittag erkannt). Ich hatte noch über einen festeren (gelöteten) Aufbau nachgedacht, aber im Moment funktioniert das mit dem Steckbrett ganz gut.

Softwareseitig bin ich auf Python umgestiegen, weil das Zusammenspiel aus Perl und pigs ziemlich viele PIDs "verbraucht" hatte (pro Messung ein neuer Prozess, mehrere Messungen pro Sekunde). In Python war das ganze sehr simpel, hier das Skript um einfach den erkannten Zustand zu spiegeln:

#!/usr/bin/python
import RPi.GPIO as GPIO
from time import sleep

SENSE_PIN = 14
LED_PIN   = 15
TIMEOUT   = 1/10.0

GPIO.setwarnings(False);
GPIO.setmode(GPIO.BCM)
GPIO.setup(SENSE_PIN, GPIO.IN)
GPIO.setup(LED_PIN, GPIO.OUT)

while True:
    state = GPIO.input(SENSE_PIN)
    GPIO.output(LED_PIN, state)
    sleep(TIMEOUT)

Die Erkennung des Festplatten-Wachzustands ist etwas kniffliger, aber auch keine Raketenwissenschaft. In der ersten Form hat das Skript einfach nur die Wechsel von idle nach active und umgekehrt in eine Textdatei protokolliert, die ich bei Bedarf manuell inspizieren konnte -- für erste Tests ausreichend.

Verändern, beoachten, auswerten

Als nächstes habe ich wieder verschiedene Zusammenstellungen der einzelnen Dienste laufen lassen und beobachtet, wann die Festplatte wach wurde. Dabei ist mir unter anderem aufgefallen, dass ich bei Gogs noch das automatische Backup aktiv hatte, das durch das tägliche Gesamtbackup überflüssig geworden ist. Weiterhin hatte ich inzwischen (zeitweise) portainer und mosquitto im Einsatz (allerdings mit Volumes auf der SD-Karte und nicht auf der Festplatte), was die Vergleichbarkeit der Ergebnisse erschwert hat. Aber eins stand schnell fest: irgendetwas weckt die Festplatte immer noch gelegentlich auf.

Eine weitere Erschwernis bestand darin, dass ich neben der Beobachtung des Durchschlafproblems auch noch den Stromverbrauch messen, an meinem Backup-Verfahren feilen und sinnvolle Ressourcen-Limits bestimmen wollte. Somit musste ich aufpassen, welche der "Aufweckungen" durch mich verursacht wurden und welche noch auf mein Problem zurückzuführen sind. Zumindest die Aufwachereignisse zwischen 0:00 und 7:00 Uhr (meistens 2-3 an der Zahl) waren weiterhin sehr verdächtig, jedoch konnte ich trotz einer längeren Beobachtungsphase keine klare Ursache/Wirkung-Beziehung zwischen dem Laufen bestimmter Anwendungen und den gelegentlichen Aufwachen der Festplatte mehr feststellen. Tendenziell habe ich immer noch Gogs und Filebrowser im Verdacht...

Wenn es zu Aufwachereignissen kommt, dann meistens in den ersten Stunden nach dem Backup, d.h. wenn die Container frisch gestartet wurden. Das spricht für "initiales Zurechtruckeln", da sich ein Container ja nicht an sein früheres Leben erinnert, mit Ausnahme der in den Volumes abgelegten Daten. Da die Wachphasen in der Regel nur 1-2 halbe Stunden ausmachen und meine Berechnung des Stromverbrauchs gezeigt hat, dass dies kaum ins Gewicht fällt, habe ich beschlossen, vorerst andere Baustellen zu adressieren und zu beginnen, meine Filebox produktiv zu benutzen.