[SOLVED] HDD Standby wird torpediert

I

ivenae

Member
Feb 11, 2022
93
30
23
41
Ich habe intern eine klassische Festplatte in meinen Server gebaut, auf welche nachts ein Backup erfolgen soll. Sie trägt die Bezeichnung /dev/sda
Die Festplatte möchte ich in den Standby schicken. Mache ich dies manuell mit hdparm -Y /dev/sda , so wacht sie einige Minuten später wieder auf.

- Die Festplatte ist nicht in der storage.cfg gelistet und auch nicht als Storage eingetragen
- Die Festplatte ist nicht gemountet und steht auch nicht in der /etc/fstab
- Prüfe ich mit biossnoo-bpfcc, so sehe ich keinen Zugriff auf diese Festplatte
- In die lvm.conf habe ich als Filter folgendes eingetragen, damit die Festplatte nicht regelmäßig von pvstatd geprüft wird:
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|","r|/dev/sd.*|"]
- Beende ich den Dienst pvstatd, so hört der Spuk auf, die Festplatte bleibt im Standby


Edit:
- Der smartd war nicht die Ursache. Der weckt die Platte zwar nach dem initialen Starten auf, läuft dann aber im Hintergrund (kein .timer Service) und lässt die Platte im Anschluss 24 Stunden in RUhe.

- fwupdmgr:
Ich hatte noch eine Auffälligkeit mit dem fwupd-refresh.timer. Der weckt die Platte auf!
Der wird nach Installation von fwupdmgr mehrfach am Tag aufgerufen, was – vorsichtig gesagt – völlig unnötig ist. Einmal die Woche sollte reichen, mir reicht sogar einmal im Monat. Also habe ich ein Override für den Timer erstellt:

mkdir -p /etc/systemd/system/fwupd-refresh.timer.d
printf "[Timer]\nOnCalendar=\nOnCalendar=monthly\nPersistent=true\n" > /etc/systemd/system/fwupd-refresh.timer.d/override.conf


Fazit:
- lvm.conf anpassen (für pvstatd) (und Service oder Server neu starten)
- fwupd-refresh.timer anpassen, falls fwupdmgr installiert ist

Beides zusammen sollte reichen, um das Problem zu lösen.

Trotzdem ist mir noch unklar, warum das zeitweise bei mir nicht funktioniert hat.
 
Last edited:
ivenae said:
Ich habe intern eine klassische Festplatte in meinen Server gebaut, auf welche nachts ein Backup erfolgen soll. Sie trägt die Bezeichnung /dev/sda
Die Festplatte möchte ich in den Standby schicken. Mache ich dies manuell mit hdparm -Y /dev/sda , so wacht sie einige Minuten später wieder auf.

- Die Festplatte ist nicht in der storage.cfg gelistet und auch nicht als Storage eingetragen
- Die Festplatte ist nicht gemountet und steht auch nicht in der /etc/fstab
- Prüfe ich mit biossnoo-bpfcc, so sehe ich keinen Zugriff auf diese Festplatte
- Den Smart Service, der die Platte nachweislich aufweckt, wurde deaktiviert
- In die lvm.conf habe ich als Filter folgendes eingetragen, damit die Festplatte nicht regelmäßig von pvstatd geprüft wird:
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|","r|/dev/sd.*|"]
- Beende ich den Dienst pvstatd, so hört der Spuk auf, die Festplatte bleibt im Standby

Kann mir jemand sagen, was genau der pvstatd (zum Teufel [!]) mit dieser Festplatte macht? Warum lässt er das Ding nicht einfach in Ruhe. Teufelszeug.
Click to expand...
Die Frage kannst du dir auch selbst beantworten. Entweder in die Doku schauen oder die Suchmaschine deiner Wahl schickt dich garantiert auch hier hin:
https://pve.proxmox.com/pve-docs/pvestatd.8.html
Der Dienst tut halt wofür er konzipiert ist und in einem echten Server setzt man eh keine DIsk in Standby.
 
  • Like
Reactions: Johannes S
Es gibt viele Gründe eine Festplatte in den Standby zu schicken:
- Langlebigkeit der Festplatte
- Stromverbrauch
- Geräuschpegel [sic!]

Die Festplatte benötigt 10 Watt Strom, also 25 € / Jahr, das sind über die Laufzeit (6 Jahre) gut 150 €. Deutlich mehr, als sie in der Anschaffung kostet.
Aus ökonomischer Sicht ist es dann sinnvoll, die Platte wegzuschmeißen und eine stromsparende SSD zu holen, die auch ohne Standby die anderen Nachteile nicht hat.

Ich verbuche deine Antwort mal unter: Aber sonst kommt von dir nur Gutes ;-)
 
Last edited:
Naja, ein Server der 24h läuft, braucht deutlich mehr Strom.
Die Technologie ist als Hypervisor für Unternehmen konzipiert, aber funktioniert auch gut im HomeLab.
Der Focus liegt aber im Stabilen Serverbetrieb und nicht im sparsamsten Home Betrieb.
Irgend einen Kompromiss muss man halt eingehen.
 
  • Like
Reactions: GMBauer and Johannes S
@ivenae Je nach Deinen Anforderungen könntest Du auch den Daemon hd-idle in Betracht ziehen, der im Repository verfügbar ist. Dieser versetzt Festplatten (standardmäßig alle, oder nach Wunsch nur bestimmte) nach einer bestimmten Inaktivitätszeit (Standard 10 Minuten) in den Standby-Modus. Ich nutze ihn mit sehr guten Ergebnissen auf meinem eigenen Server mit 8 2,5"-Platten und 4 3,5"-Platten; der "heiße" Storage ist eine SSD und die Daten auf den HDDs wird nur sehr selten und von nur sehr wenigen potenziellen Nutzern abgerufen, sodass es kein Thrashing gibt und auch keinen wirklichen Grund zur Sorge.

(Entschuldige, falls mein Deutsch etwas eingerostet ist – ist schon ein paar Jahre her.)
 
Falk R. said:
Der Focus liegt aber im Stabilen Serverbetrieb und nicht im sparsamsten Home Betrieb.
Click to expand...
Man kann das nicht oft genug betonen, für die meisten Homeuser ist ein beliebiges NAS mit docker- ("Apps") und VM-Support sinnvoller. Da gibt es mit unRAID, OpenMediaVault und TrueNAS ja auch Linux basierende Alternativen zu den Systemen von Synology, OnTAP und co, die sich auf typischer Homeserver-Hardware installieren lassen.
 
- Mein "Homelab"-Server benötigt 10 W Strom. Die verbaute 3,5" Festplatte verdoppelt den Strombedarf, dabei läuft sie nur nachts für 20 min. Das ist prozentual und absolut gesehen durchaus relevant, außerdem ist sie laut. Das Gerät arbeitet mehr oder weniger lüfterlos.

- hd-idle hindert ja nicht den Rest des Systems daran, die Platte 'alle Nase lang' wieder zu starten, da hilft mir hd-idle nicht. Das zu verhindern habe ich oben nun dokumentiert. Ich verwende ein '@reboot hdparm -S 3 /dev/sda' crontab. Das erfüllt den gleichen Zweck.

- Ich benutze Proxmox aus Überzeugung und als Testsystem für die ansonsten etwas größeren Systeme, für deren Wartung ich zuständig bin. Es wäre blöd, wenn ich im privaten keine Erfahrung sammeln kann/soll/darf, wenn ich Sie beruflich benötige. Die verfügbaren Skripte zur Installation von LXC Containern sind für mich ein Optimum an: Ich verstehe, was unter der Haube abgeht und kann ggf. individuelle Konfigurationsänderungen durchführen, aber muss nicht jede config Datei mühsam selbst zusammenstricken. Das mag ich an dem Gesamtsystem im Homelab. Ohne unraid im speziellen zu kennen, ich vermute das geht mir zu weit in Richtung Kontrolle abgeben. Die Geräte von Synology oder qnap kommen wir schon prinzipienbedingt nicht auf den Tisch: Langsame, teure Hardware, meist nicht x86 kompatibel, zu wenig RAM und der ist nicht erweiterbar, und zu allem kommen dann auch noch die Versuche, Zollabgaben für Speichermedien in der Größenordnung mehrerer 100 % zu verlangen.
 
Last edited:
You must log in or register to reply here.
Top Bottom