WD Red 10TB - Probleme mit HDD-Standby und SMART

Vielen Dank für die schnelle Antwort. Ich habe übrigens diesen interessanten Beitrag gefunden (bit.ly/2vwawFr ) und jetzt mal testweise den smartd prozess gestoppt.

Die Platte ist jetzt mit -B127 und -S120 eingestellt. Deine letzten beiden Befehle liefern keine Ausgaben. Nach journalctl steht der Curso unter dem Befehl ohne dass ein neuer Prompt kommt und es kommt auch keine Ausgabe. Ich nehme an es ist so zu verstehen, dass dann also kein Zugriff stattfindet. Wobei ich nicht verstehe warum man eine 1 in die Datei block_dump schreibt.

Jedenfalls geht die Platte nicht in den Ruhezustand. Ich stoppe jetzt den minidlna Prozess mal zur Sicherheit.

Bei hd-idle war ich so vorgegangen: bit.ly/2GTNNIu.

Irgendwo gab es auch einen guide, der beschrieb, wie man die Funktionsweise von hd-idle vor Nutzung mit einem Kommando testen kann. Das hatte ich getan und die Disk hätte sofort in den Ruhezustand fahren müssen und das ging eben nicht. Da auch der zeitgesteuerte Betrieb nicht funktionierte hatte ich das dann verworfen. Vor allem, weil ich mich frage, die hd-idle funktioniert. Ich denke, es ist einfach nur ein Skript, was hdparm -y nutzt. Es wird ja keine eigenen ATA-Befehle extra entwickelt haben.
 
bvrulez schrieb:
Die Platte ist jetzt mit -B127 und -S120 eingestellt. Deine letzten beiden Befehle liefern keine Ausgaben. Nach journalctl steht der Curso unter dem Befehl ohne dass ein neuer Prompt kommt und es kommt auch keine Ausgabe. Ich nehme an es ist so zu verstehen, dass dann also kein Zugriff stattfindet. Wobei ich nicht verstehe warum man eine 1 in die Datei block_dump schreibt.
Also nach 10m Standby, richtig? Dass der Cursor stehen bleibt ist richtig. Wenn Zugriffe stattfinden, siehst du diese. Also im Idealfall 10m laufen lassen, wenn immer noch nichts angezeigt wird und die Platte nicht in den Standby geht, sind Festplattenzugriffe von Programmen (weitestgehend) ausgeschlossen.

Das X in "journalctl -f | grep sdX" hast du aber durch den Bezeichner der 10TB Platte ersetzt, oder? Ein "journalctl -f" sollte eine Menge an Festplattenzugriffe ohne Filter zeigen, also vor allem der Systemplatte. Ggf wird auch gar nicht ins systemd journal geloggt, dann "journalctl -f" einfach mal nach "dmesg" ersetzen. Ich musste solche Analysen noch nicht auf einem Pi machen. ;)

//edit: Gerne auch einen Gegencheck in einem weiteren Terminal machen: Ein ls /<mountpoint der Festplatte> sollte eine Ausgabe verursachen.

Die "1" in der Datei block_dump aktiviert das logging für Disk reads/writes. Sollte nach Nutzung übrigens wieder deaktiviert werden, indem "0" in die Datei geschrieben wird. Wird aber auch nach einem Neustart zurückgesetzt.

Siehe auch: https://www.thomas-krenn.com/de/wiki/Per_Prozess_I/O_Statistiken

bvrulez schrieb:
Ich denke, es ist einfach nur ein Skript, was hdparm -y nutzt.
Soweit ich weiß, ja. Bzw. eher den gleichen Befehl direkt an die Festplatte schickt, denn es hat keine Abhängigkeit zu hdparm.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bvrulez
Danke vielmals! Ja, ich hatte das richtige Device angesprochen, habe es jetzt aber auch nochmal getestet. 50 Minuten lang kein journalctl auf sdb. Mit ls dann ein read von einem block. Und damit wieder was gelernt! Ein dmesg | grep sdb, den ich direkt danach ausprobiert habe, bringt diesen einen read und gibt mir dann wieder einen prompt. Bis auf mounten habe ich mit der Platte seit dem letzten Neustart des Pi heute Nacht aber auch nichts gemacht. Block_dump enthält immer noch die 1.

Ein upgrade der Raspian-Installation kann ich derzeit noch nicht machen, weil die SD-Karte 8GB groß ist und fast gefüllt und ein Update offenbar 1GB hinzufügt. Kommt mir zwar etwas viel vor, weil ich eigentlich nur einen logitechmediaserver drauf laufen habe, aber will kein Risiko eingehen.
 
bvrulez schrieb:
Ein dmesg | grep sdb, den ich direkt danach ausprobiert habe, bringt diesen einen read und gibt mir dann wieder einen prompt.
Ups, "dmesg -w" wäre richtig gewesen. Aber ist eh egal, wenn journalctl die Daten enthält.

Somit klingt es ziemlich ähnlich zu dem Problem, welches ich hatte. Wo - wahrscheinlich - eines der letzten hdparm Updates geholfen hat.

Alternativ halt nochmal hd-idle ausprobieren. Existiert die Datei /proc/diskstats bei dir? Ich meine, dass war die Datei, die hd-idle auswertet, um Inaktivität zu erkennen. Wenn ja, hd-idle im terminal testen: hd-idle -a sdb -i 300 für Spindown nach 5m, bzw. sofortiges Spindown mit: hd-idle -t sdb

//edit: Wichtig: hd-idle als root ausführen
 
Ja, die Datei existiert, das hatte ich damals gecheckt. Etwas ähnliches wie hd-idle -a sdb -i 0 hatte ich zum sofortigen Spindown verwendet und das hat nicht funktioniert. Danke für das Feedback! Es ist ja auch gut, wenn man einfach weiß, dass man auf der richtigen Spur ist. Ich werde demnächst das Update machen und vielleicht wird dann mit einem neuen Kernel alles besser, oder ich teste hd-idle nochmal.
 
Ja, bin mir unsicher, ob ich dieses Kommando verwendet hatte. Jedenfalls hatte ich eins verwendet, um den sofortigen Spindown zu testen. Ich hab jetzt hd-idle v1.05 nochmal installiert, die config angepasst mit der UUID meiner Festplatte und mit hd-idle -t sdb auch versucht sie sofort runterzufahren. Passiert nichts. Habe dann APM der Festplatte von 254 auf 255 gestellt, passiert auch nichts. Offenbar war der APM übrigens nach Neustart der Platte (ein/aus) resettet. Hatte vorher auf 127, wenn ich mich richtig erinnere.

Jedenfalls läuft es nicht. Letzte Option ist das Upgrade auf Stretch.
 
So, nachdem ich eine größere SD-Karte bestellt und meinen Raspberry von Jessie auf Stretch geupgraded läuft es wieder mit hdparm -y. Auch die Einstellung mit hdparm -S100 scheint zu funktionieren, allerdings nicht immer. Gestern hatte ich bspw. den TV eine Stunde an und habe von der Platte per DLNA gestreamt. Danach den TV vom Strom getrennt und die Platte fuhr nicht runter. Mehrmalig hab ich das mit unterschiedlichen Timereinstellungen versucht. Möglicherweise ist die Platte dann zu heiß und muss erst abkühlen oder es wird eine Art Wartung durchgeführt?

Übrigens legen die Werte oberhalb von 240 keine Minuten mehr fest, sondern:

  • S241: 30 Min
  • S242: 1 H
  • ...
  • S250: 5 H
 
Zuletzt bearbeitet:
-S 1 - 240 spezifiziert einen Faktor von 5 Sekunden, nicht Minuten. Steht aber auch so in der Manpage:
Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30
minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some
older drives may have very different interpretations of these values.

Zum Problem:
Evt. greift da noch was auf die Festplatte zu. Ich hatte das damals auch oft, wenn MiniDlna laufen lassen hatte. Irgendwas im Netz hat dann drauf zugegriffen und den Spindown verhindert. Oder die Platten fahren wieder hoch, wenn die Files Indexiert werden.

Du könntest das ganze wieder mit "echo 1 > /proc/sys/vm/block_dump" prüfen. Oder via /proc/diskstats

Es gibt auch noch andere Tools, die dir Festplattenaktivität anzeigt. Bspw. jede Minute die Anzahl der Block reads/writes anzeigt. Leider fallen mir diese gerade nicht ein.

Ansonsten noch: Denk dran, dass du den Spindown Timeout nach einem Neustart neu setzt.
 
Mit der Einstellung hdparm -B100 scheint das Klicken übrigens gelegentlich zu stoppen, was schon mal sehr schön ist. Ich vermute, dass die Leseköpfe dann geparkt werden, ohne die Spindel herunterzufahren. Das Parkgeräusch ist jedenfalls das gleiche, bis auf den Spindown. Das wäre sicherlich für diese NAS-Platte eine gute Sache hinsichtlich der Lebensdauer. Den Befehl hab ich nun in /etc/rc.local hinterlegt.

Allerdings weckt die Platte alle 10 Minuten für 1-2 Minuten auf, sowohl mit -B10, -B127 oder -B100. Danach parkt sie die Köpfe wieder.

Nun habe ich mit -S10 in den Spindown geschalten und nach 10 Minuten ist die Platte immer noch ruhig.
 
Zuletzt bearbeitet:
Zurück
Oben