Die Festplatte, die nicht schlafen wollte — und warum jedes Nachsehen sie weckte

Ein Unraid-Server legt seine Festplatten schlafen, wenn eine Weile niemand auf sie zugreift. Das spart Strom, hält den Schrank leise und schont die Mechanik. Bei mir taten das auch alle Platten brav — bis auf eine. Die lief rund um die Uhr, ohne erkennbaren Grund.

Der erste Reflex ist immer derselbe: Irgendein Programm muss ständig darauf zugreifen. Also sucht man den Übeltäter. Nur: Die Zugriffszähler des Systems, die jeden Lese- und Schreibvorgang auf der Platte mitzählen, rührten sich nicht. Kein Zugriff — und trotzdem hellwach.

Das Messgerät war das Problem

Hier fängt der eigentliche Fall an. Um herauszufinden, wer eine Platte beschäftigt, will man nachsehen, was auf ihr los ist: die Verzeichnisse auflisten, die Dateien durchzählen, den Belegungsstand prüfen. Genau das war die Falle.

Jeder dieser Blicke weckt die Platte selbst. Ein Verzeichnis aufzulisten heißt, die Platte zu lesen — und schon dreht sie wieder an. Ich saß also vor einem Phänomen, das erst durch das Messen entstand. Zweimal habe ich mich damit auf eine falsche Fährte locken lassen: „Da liest doch alle paar Minuten jemand!" — bis mir dämmerte, dass dieser Jemand mein eigenes Nachsehen war.

Das Werkzeug, mit dem ich den Verursacher suchte, war der Verursacher.

Die Lehre daraus bestimmte den Rest der Diagnose: nur noch aus sicherer Entfernung messen. Es gibt einen Befehl, der den Schlafzustand einer Platte abfragt, ohne sie dabei zu wecken. Und es gibt die Zugriffszähler des Systems, die man lesen kann, ohne die Platte anzufassen. Alles andere — jedes „ich schau nur kurz" direkt auf der Platte — war ab da verboten.

Zwei Verdächtige, beide gemessen statt vermutet

Mit dieser Regel ließen sich die naheliegenden Verdächtigen der Reihe nach prüfen — nicht durch Nachdenken, sondern durch Messen.

Verdächtiger eins: das Synchronisationsprogramm. Auf genau dieser Platte lagen mehrere Ordner, die per Syncthing mit anderen Geräten abgeglichen werden. Ein perfekter Kandidat. Also habe ich einen vollständigen Abgleich von Hand ausgelöst — über 500 Dateien — und dabei die Platte beobachtet. Sie blieb im Schlaf, kein Zähler bewegte sich. Freigesprochen. Hätte ich hier geraten statt gemessen, hätte ich die Ordner umständlich umgezogen und die Platte liefe heute noch.

Verdächtiger zwei war in Wahrheit ein Beschützer. Es gibt ein Unraid-Zusatzmodul, das die Verzeichnisstruktur im Arbeitsspeicher hält, damit Programme, die nur „was liegt hier?" fragen, gar nicht erst die Platte wecken. Man könnte es für einen Verursacher halten — es ist das Gegenteil. Ein direkter Vergleich über je zehn Minuten bei schlafender Platte: mit dem Modul null Weckvorgänge, ohne das Modul sechs, der erste schon nach 21 Sekunden. Dieses Modul abzuschalten, um ein Spindown-Problem zu suchen, macht es also schlimmer, nicht besser.

Der eigentliche Schuldige: die Überwachung selbst

Blieb die unbequeme Möglichkeit, dass kein Programm schuld ist, sondern Unraid sich selbst wach hält. Genau so war es.

Unraid fragt in regelmäßigen Abständen die Gesundheitswerte (SMART) aller Platten ab, die es für laufend hält — Temperatur, Fehlerzähler, Betriebsstunden. Das ist sinnvoll. Der Haken: diese Abfrage weckt eine schlafende Platte, erzeugt dabei aber keinen normalen Lese- oder Schreibzugriff. Für den Ruhe-Timer, der auf genau solche Zugriffe wartet, sieht es aus, als sei nichts passiert — also stellt er sich nie neu. Die Platte läuft weiter, die nächste Gesundheitsabfrage kommt, weckt sie erneut, und der Kreis schließt sich.

Warum traf es nur diese eine Platte? Weil ein internes Zustandsflag bei ihr fälschlich auf „läuft" stand. Platten, die korrekt als „schlafend" vermerkt sind, überspringt die Abfrage — sie werden nicht geweckt. Nur bei der einen mit dem falschen Flag biss sich die Katze in den Schwanz.

Die Behebung — und warum sie bis heute nötig ist

Von Hand ließ sich die Platte über das System selbst korrekt schlafen legen. Wichtig war, das dem System zu überlassen und nicht die Platte direkt anzuhalten: Tut man Letzteres, bleibt das falsche Flag stehen, die nächste Gesundheitsabfrage weckt sie sofort wieder, und man ist keinen Schritt weiter.

Dauerhaft habe ich einen kleinen Wächter eingerichtet, der alle fünf Minuten läuft. Er erkennt die verräterische Kombination — „seit Längerem kein echter Zugriff, aber vom System als laufend gemeldet" — und legt die Platte dann sauber über das System schlafen. Während eines laufenden Prüflaufs oder Umräumvorgangs hält er sich zurück, um nichts zu stören.

Das Ernüchternde: Dieser Wächter ist kein Andenken an ein gelöstes Problem, sondern trägt die Sache bis heute. Noch gestern hat er eine Platte eingefangen, die das System nach über neun Tagen immer noch für laufend hielt. Der Grundfehler steckt tief im System und ist nicht behoben — der Wächter gleicht ihn nur zuverlässig aus.

Für alle, die dasselbe messen wollen

Die Diagnose in Befehlen — der Dienst, der die Platten überwacht und schlafen legt, heißt emhttpd, das Zustandsflag spundown in /var/local/emhttp/disks.ini, und das Zusatzmodul, das die Verzeichnisstruktur im Arbeitsspeicher hält, Dynamix Cache Dirs.

hdparm -C /dev/sdX             # Schlafzustand abfragen, ohne zu wecken
grep rdev /proc/mdstat         # Zugriffszähler, zweimal im Abstand von 30 s
hdparm -y /dev/sdX             # schlafen legen und dann beobachten:
ps -ef | grep smartctl         # der Verursacher erscheint beim nächsten Poll
emcmd "cmdSpindown=disk2"      # richtig schlafen legen - über den Dienst!

Die letzte Zeile ist der Unterschied zwischen Heilung und Wiederholung: hdparm -y hält die Platte zwar an, lässt aber das Flag auf 0 stehen — die nächste Gesundheitsabfrage weckt sie sofort wieder. Und die wichtigste Regel steht in keinem Befehl: während der Messung /mnt nicht anfassen. Jedes ls, find oder du dort weckt die Platte selbst und verdrängt obendrein genau die Verzeichnisdaten, die das Zusatzmodul im Arbeitsspeicher hält.