Problem mit HDD Spindown

S

Schmiddi

New Member
Apr 10, 2025
6
1
3
Hallo zusammen,
nach häufig unregistriertem mitlesen und einem für mich nicht lösbaren Problem, habe ich nun endlich mal einen Account erstellt und wende mich hilfesuchend an euch.

Erst seit ein paar Wochen habe ich eine Toshiba MG10 an meinem kleinen Heimserver, die lediglich als Medien-Datengrab dient. Zunächst habe ich sie kontinuierlich drehen lassen und nachdem sie vollendens gefüttert wurde, je nach Bedarf auch mal eine ganze Woche nicht benötigt wird, wollte ich sie zwischen den Nutzungen in den Standby schicken.
Und jetzt kommt es zum Problem.
Alle 12h erfolgen Zugriffe die ich bisher noch nicht nachverfolgen konnte und somit wollte ich Spindown wieder deaktivieren, funktioniert jedoch nicht wie gedacht!

IST-Zustand:
  • CWWK n305 Host
  • HDD via SATA angeschlossen
  • /etc/fstab:
Code: 
UUID= ... /mnt/toshiba0  ext4  defaults,nofail,barrier=1  0  0
  • via Bindmount an Debian LXC weitergereicht
  • Debian LXC stellt SMB-Share bereit
  • Zugriff auf Networkshare: Jellyfin LXC, eine VM mit verschiedenen Docker Containern
  • Zwei Personen Haushalt, Zugriffe durch User leicht zu identifizieren
  • hd-idle.log zeigt Zugriffe immer um ~05:00 und ~17:00

Was wurde versucht:
  • hdparm -B 127 /dev/sda (mittlerweile wieder 254)
  • hdparm -S 240 /dev/sda (mittlerweile wieder 0)
  • entsprechender Eintrag in /etc/hdparm.conf war
Code: 
/dev/disk/by-id/ {
        apm = 127
        spindown_time = 240
}
  • /etc/smartd.conf
Code: 
/dev/sda -n idle,q
Auch wenn es eigtl nur Abhilfe schaffen soll wenn die Platte bei Proxmox als Storage eingefügt ist, habe ich folgendes versucht
  • /etc/lvm/lvm.conf
Code: 
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|","r|/dev/sda|","r|/dev/rbd.*|","r|/dev/sda1|"]
  • hd-idle installiert mit entsprechendem Eintrag in der /etc/default/hd-idle
Code: 
hd-idle -a sda -i 1800 -l /var/log/hd-idle.log
-i dann auch wieder auf 0 bzw weggelassen und hd-idle mittlerweile deinstalliert.


Das waren alle Versuche um einen zuverlässigen Spin-Down hinzubekommen, durch die Zugriffe alle 12h wollte ich es jedoch rückgängig machen.
Mit dem nun deinstallierten hd-idle und hdparm -B 254 -S 0 fährt die Platte aber nach 5min runter. Klasse! Das was ich vorher mit viel Sucherei/rumprobiererei einrichten wollte, klappt jetzt ohne jegliches Zutun :D

Ich komme an der Stelle nicht weiter, mein Lösungsansatz wäre es, entweder ausfindig machen was alle 12h auf die Festplatte zugreift (ich habe Jellyseerr im Verdacht, bin mir jedoch nicht sicher) und dies unterbinden, oder eben den Spin-Down wieder gänzlich ausschalten und die Platte 24/7 durchdrehen lassen.

Eigentlich wäre ich für ersteres gewillt, da es wie beschrieben auch mal sein kann, dass die Platte ein, zwei Wochen oder gar noch länger gar nicht benötigt wird.
Wäre mit beiden Varianten jedoch d’accord, Hauptsache die Platte fährt nicht ständig hoch/runter

Seit 21.03.2025:
Code: 
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       502
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       74

Vielen vielen Dank fürs lesen!
Hoffe ihr könnt mir helfen

Gruß
Schmiddi

edit: Ich habe Proxmox seit hd-idle uninstall nicht neugestartet, falls das zu Problemen führen könnte. Starte nur dann wenn es sein muss neu, da ich mir einen massiven Single-Point of Failure gebaut habe ;)
 
Last edited:
Schade dass mir bisher niemand weiterhelfen konnte.
Leider konnte ich das Problem auch nicht "sauber" lösen, weder in die Richtung zuverlässiger Standby oder dauerhaftes Spinning.

Bezüglich Standby bekomme ich nach allen Versuchen mit smartd, hd-idle, hdparm und rückgängig machen mittlerweile auf fünf unerwünschte Wake-Ups pro Tag.

Dauerhaftes Spinning, obwohl APM auf 255, Spinning Down Timer auf 0 und hd-idle deinstalliert usw. habe ich so auch nicht hinbekommen, die Platte geht einfach immer wieder in den Standby. So habe ich letzten Endes ein kleines Keepalive Script was via Cron alle 10 Minuten einen Minimalzugriff auf die Festplatte ausübt und so wach hält.
Nicht schön, aber anders seh ich mit meinem Wissen keine Möglichkeit.

SMART sieht mittlerweile wie folgt aus, da möchte ich die Enterprise Platte auch nicht weiter quälen
Code: 
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       73
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       646
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       109
 
Hi,
ich habe noch nie mit Spindown gearbeitet, ich verhindere eher soetwas. Bei einem Hypervisor macht soetwas keinen Sinn. Entweder reichst du den Controller samt Disk(s) an eine VM durch, wo du das konfigurierst, oder installiere lieber ein NAS OS mit virtualisierungsfunktion, als einen echten Hypervisor.
 
  • Like
Reactions: Schmiddi
Wie @Falk R. schreibt, die gesamte Platte inklusive Controller an eine VM durchzureichen, funktioniert bei mir einwandfrei.

Ich hab eine VM mit Cockpit/45Drives als FileServer, an dem eine 16TB USB-Platte (Filme/Serien/Musik) hängt. Den Standby der Platte steuere ich über HD-Idle in der VM. Und die schläft bombenfest ...

Code: 
date: 2025-03-31, time: 05:05:24, disk: sdb, running: 372, stopped: 133583
date: 2025-04-04, time: 06:41:39, disk: sdb, running: 372, stopped: 3473
date: 2025-04-05, time: 10:58:19, disk: sdb, running: 310, stopped: 101489

... auch mehrere Tage, wenn die Enkelkinder nicht mit Kodi darauf zugreifen.
 
  • Like
Reactions: Schmiddi
Danke für eure Antworten!
Cockpit/45Drives Tools nutze ich auch, nur eben auf einem Debian LXC, ein vollwertiges (überladenes) NAS OS benötige ich nicht, aber hier ist wohl der Knackpunkt.
Meines Wissens nach, kann ich nicht die Platte inklusive Controller, also PCI Passthrough, an einen LXC durchreichen.

Wenn sich die genannte Problematik damit wirklich lösen lässt, dann würde ich den LXC gegen eine Debian VM ersetzen.

Dazu der Vollständigkeit halber noch eine Frage. Bisher habe ich nur die NICs meines Hosts an meine OPNsense VM via PCI Passthorugh im Proxmox GUI durchgereicht. Das sind neben dem NVMe Controller und der iGPU auch die einzigen Devices die eine Bezeichnung haben.

Code: 
root@proxmox:~# lspci | grep -i sata
00:17.0 SATA controller: Intel Corporation Alder Lake-N SATA AHCI Controller

root@proxmox:~# find /sys/kernel/iommu_groups/ -type l | grep 17.0
/sys/kernel/iommu_groups/6/devices/0000:00:17.0

Ich denke das ist der korrekte Weg, zu identifizieren welches PCI Device ich in der GUI dann durchreichen kann?
 
Bei einem LXC hast du immer den Hostkernel, welcher mit den Devices spricht. In einem Hypervisor will man kein Spindown haben, also entweder auf VM wechseln oder ProxmoxVE ist nicht das richtige Produkt für deinen Anwendungsfall.
 
Doch PVE ist völlig richtig für meinen Anwendungsfall.
Nur weil ich erst seit kurzem zusätzlich einen LXC als NAS aufgesetzt habe, was anscheinend die falsche Vorgehensweise war, heißt das nicht dass ich PVE ausschließlich dafür nutze.

Daher auch die Frage ob die oben erwähnte Vorgehensweise zum Ausfindig machen der korrekten ID für das PCI Device so korrekt ist.


Weil ich gerade Zeit habe (und auf Rückmeldung gewartet habe), versuche ich es aber aktuell noch mit dem LXC ohne Bindmounts sauber hinzubekommen.
Ist halt nur die Frage ob ich mir das hätte sparen können und die Zeit besser in das Aufsetzen und Konfigurieren der NAS VM investiert hätte :D

Habe die lxc.conf wie folgt angepasst
Code: 
lxc.cgroup2.devices.allow: b 8:0 rwm
lxc.mount.entry: /dev/disk/by-id/ata-TOSHIBA_MG10 dev/toshiba0 none bind,optional,create=file
lxc.cgroup2.devices.allow: b 8:1 rwm
lxc.mount.entry: /dev/disk/by-id/ata-TOSHIBA_MG10-part1 dev/toshiba0p1 none bind,optional,create=file
lxc.apparmor.profile: unconfined
lxc.cap.drop:

Alle Mounts aus der PVE fstab entsprechend entfernt und bisher habe ich testweise mit hdparm -I vollen Einblick innerhalb des Containers.
 
  • Like
Reactions: Ernst T.
Mit lsblk -fs oder ls -l /dev/disk/by-id/ sehe ich die Platte schon noch.
Habe händisch smartmontools so konfiguriert, dass er diese Platte nicht mehr überwacht und dafür im LXC so eingerichtet.
Generell versuche ich alles was ich für die Platte auf dem Host versucht habe, einfach auf den LXC zu verschieben. Wenn es nicht klappt war es vergebene Mühe, oder einfach eine Erfahrung reicher - wie man es sieht - und dann richte ich eine VM mit PCI Passthrough der Platte ein.
 
Feedback
Bis jetzt funktioniert es wie gewünscht im LXC! Der Test ist jetzt natürlich noch nicht so ausführlich nach gestriger Umsetzung, aber mehrere Stunden ACTIVE ohne ungewolltes IDLE/STANDBY haben funktioniert und gegen 19:30uhr habe ich die Platte manuell in den STANDBY geschickt woesie bisher auch geblieben ist. Wenn das so bleibt, optimal :)

Zusammenfassend
PVE-Host
  • Mount der Platte aus /etc/fstab entfernt (cifs mounts bestehen gelassen)
  • hdparm Konfiguration für diese Platte auskommentiert
  • hd-idle deinstalliert
  • Diese Platte explizit in smartd.conf ausgeschlossen
  • lxc.conf wie in Post #7 beschrieben angepasst
NAS LXC
  • systemd Mount für die Festplatte erstellt
  • smartd.conf auf standby Betrieb angepasst (msmtp für SMART Mail Benachrichtigungen eingerichtet)
  • hd-idle für Logging und Standby nach 30min konfiguriert
  • hdparm.conf -S 0 -B127
 
You must log in or register to reply here.
Top Bottom