Festplatte (Western Digital, 10TB) in den Standby schicken

Nach dem Kauf einer Western Digital Red (10TB) stellte ich fest, dass diese im Guten nicht in den Standby bzw. Suspend geht. Nachdem ich viel zu dem Problem las, fand ich mich damit ab, dass ich mich wohl mit herkömmlichen Mitteln herumschlagen müsste.

hdparm -Y /dev/sdX

So weit, so gut. - Die Festplatte fährt runter. Aber...sie geht nach kurzer Zeit auch wieder an.

Es scheint also so, als griff ein Prozess im Hintergrund auf die Festplatte zu. Das wäre nachvollziehbar, wenn die Partition eingehängt wäre. Ist sie aber nich; mehr noch, sie ist verschlüsselt und nicht mal mittels *Luks dem System bekannt gemacht. Wer oder was greift also auf das "Raw-Device" zu?

Das Tool blktrace verspricht einen Lösungsweg. Mit diesem Werkzeug lassen sich sämtliche Zugriffe im Low-Level-Bereich überwachen. apt-get install blktrace

blktrace ls solches bringt erstmal noch nicht so viele zielführende Informationen: blktrace -d /dev/sdX

=== sdX === CPU 0: 0 events, 0 KiB data CPU 1: 0 events, 0 KiB data CPU 2: 0 events, 0 KiB data CPU 3: 0 events, 0 KiB data CPU 4: 0 events, 0 KiB data CPU 5: 0 events, 0 KiB data CPU 6: 1 events, 1 KiB data CPU 7: 0 events, 0 KiB data Total: 1 events (dropped 0), 1 KiB data

Mit dem Tool blktrace kommt auch das Tool btrace mit. Dieses lässt sich für unsere Zwecke nutzen: btrace /dev/sdX

8,16 2 1 0.000000000 11417 G N [hdparm] 8,16 2 2 0.000000997 11417 I N 0 [hdparm] 8,16 2 3 0.000001959 11417 D N 0 [hdparm] 8,16 4 1 0.610846161 0 C N [0] 8,16 5 1 0.610903194 9075 G N [kworker/u16:4] 8,16 5 2 0.610903867 9075 I N 0 [kworker/u16:4] 8,16 5 3 0.610904465 9075 D N 0 [kworker/u16:4] 8,16 5 4 0.610913179 40 C N [0]

Wie man unschwer erkennen kann, greift der Prozess hdparm auf das Gerät zu; die Festplatte geht schlafen. ...und erwacht plötzlich:

8,16 4 2 69.824576715 816 G N [smartd] 8,16 4 3 69.824577869 816 I N 0 [smartd] 8,16 4 4 69.824578545 816 D N 0 [smartd] 8,16 4 5 75.379210845 72 G N [kworker/4:1] 8,16 4 6 75.379214100 72 I R 255 [kworker/4:1] 8,16 4 7 75.379214764 72 D R 255 [kworker/4:1] 8,16 4 8 75.379218780 72 R R [0] 8,16 4 9 75.379219024 72 I R 255 [kworker/4:1] ...

Ahha! Wenn der Prozess von "SmartMonTools" den Status der Geräte abfragt, dann ändert er den Status. - Das ist ja wirklich smart. - Niiiiicht!

Kurzer Test: ps ax | grep smart

816 ? Ss 0:00 /usr/sbin/smartd -n

kill -9 816 Nun müsste der Störenfried ausgeschaltet sein. Also, erneut: btrace /dev/sdX

8,16 4 1 0.000000000 14081 G N [pool] 8,16 4 2 0.000000577 14081 I N 0 [pool] 8,16 4 3 0.000001015 14081 D N 0 [pool] 8,16 4 4 5.384266703 13004 G N [kworker/4:5] 8,16 4 5 5.384272306 13004 I R 255 [kworker/4:5] 8,16 4 6 5.384273542 13004 D R 255 [kworker/4:5] 8,16 4 7 5.384280168 13004 R R [0]

Hmmmm, blöd!

Das "Poll" kommt vom Kernel. - So sollte es jedenfalls sein. Seltsamerweise kann man dieses Verhalten jedoch unterbinden, indem man den Dienst "udisks2" abwürgt. Das ist nun bereits der zweite Dienst, der eigentlich eine helfend-unterstützende und zudem noch "festplattenlebensverlängernde" Aufgabe erfüllen sollte. Dass hdparm -C die Festplatte weckt, scheint ein Firmware-Fehler im Festplattenkontroller zu sein. Dass "udisk2" jedoch in den Prozess eingreift, ist "ein" Fehler in den Diensten. "udisk2" will den Status abfragen und kommt dabei mit den Suspend-Funktionen in Konflikt. Es gibt Lösungen für das Problem - man müsste intern das Timing manipulieren - aber die einfachste und zuverlässigste aller Lösung ist zudem auch gleich mal die rabiateste:

#!/bin/sh
sudo systemctl stop smartd
sudo systemctl stop udisks2
sudo hdparm -Y /dev/sdX

Ich bin nicht stolz auf die "Lösung", die in Wirklichkeit ja gar keine ist, aber dieses Vorgehen löst wenigstens ein Problem.

Kleiner Nachtrag:

Fährt man den Rechner runter, fährt besagte, schlafende Festplatte erst mal hoch, um sofort wieder auszugehen. Ich mag mich irren, aber so richtig toll ist das nicht. ...es wird wohl langfristig auf ein externes Festplattengehäuse hinauslaufen. ;-)