Auf meinem NAS läuft derzeit debian (gebootet von USB-Stick) und ich habe Probleme damit die interne HDD in den standby zu schicken. Normalerweise sollte das ja mit hdparm -S 120 /dev/sda funktionieren und die Plattenach 10 Minuten in den standby gehen. Leider funktioniert das aber nicht! Allerdings kann ich mit dem Parameter -y die Platte sofort und ohne Probleme in den standby schicken. Sie wacht dann auch erst wieder auf wenn auf ihren Inhalt zugegriffen wird. Hat jemand einen Tip?
1 | hdparm -B <Wert kleiner als 127 hier einfügen> /dev/sda |
Von der Man-Page("man hdparm"):
1 | -B Get/set Advanced Power Management feature, if the drive supports it. A low value means |
2 | aggressive power management and a high value means better performance. Possible settings |
3 | range from values 1 through 127 (which permit spin-down), and values 128 through 254 (which |
4 | do not permit spin-down). The highest degree of power management is attained with a set‐ |
5 | ting of 1, and the highest I/O performance with a setting of 254. A value of 255 tells |
6 | hdparm to disable Advanced Power Management altogether on the drive (not all drives support |
7 | disabling it, but most do). |
Ich würde es zuerst mit 255 probieren(siehe hier: http://linuxwiki.de/hdparm#Vorwort_und_Beispiel_f.2BAPw-r_Settings_in_die_Harddisk_Elektronik) und wenn das nicht funktioniert mit 127.
Funktioniert leider nicht: "APM_level = not supported" Es handelt sich übrigens um eine WD Caviar green. Den idle3timer hatte ich übrigens schon direkt nach Erhalt der Platte deaktiviert (intellipark). Aber das hat ja nichts mit dem spindown / standby zu tun.
:
Bearbeitet durch User
Funktioniert es auch mit -B 255 (trotz der Fehlermeldung) Nicht? Ist das ding über USB angeschlossen? Ansonsten: http://linuxwiki.de/hdparm#disk_spindown.sh
1 | -S Put the drive into idle (low-power) mode, and also set the standby (spindown) timeout for the drive. This |
2 | timeout value is used by the drive to determine how long to wait (with no disk activity) before turning off |
3 | the spindle motor to save power. Under such circumstances, the drive may take as long as 30 seconds to |
4 | respond to a subsequent disk access, though most drives are much quicker. The encoding of the timeout |
5 | value is somewhat peculiar. A value of zero means "timeouts are disabled": the device will not automati‐ |
6 | cally enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 |
7 | seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts |
8 | from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a ven‐ |
9 | dor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 |
10 | minutes plus 15 seconds. Note that some older drives may have very different interpretations of these val‐ |
11 | ues. |
Prima, mit dem Skript klappt es nun. Wie mache ich das denn am geschicktesten, dass es automatisch beim booten im Hintergrund läuft? Ein Aufruf des Skripts in rc.local brachte nicht das gewünschte Ergebnis.
> Ein Aufruf des Skripts in rc.local brachte nicht das gewünschte > Ergebnis. Dann mach es nochmal richtig.
Vlt. Im hintergrund Starten? (Mit nem "&" am schluss) Was bringt "systemctl status rc.local"?
Kann die Platte die Einstellung nicht dauerhaft speichern?
Lukas S. schrieb: > Vlt. Im hintergrund Starten? (Mit nem "&" am schluss) Ja das funktioniert. Aber jedes mal einloggen und das Skript per Konsole starten ist ziemlich nervig. Lukas S. schrieb: > Was bringt > "systemctl status rc.local"? Da taucht das skript leider nicht auf. batman schrieb: > Kann die Platte die Einstellung nicht dauerhaft speichern? Nein, die Parameter -B und -S akzeptiert die Platte nicht.
Ich mein in der rc.local und aufpassen, dass es vor dem exit 0 ist.
Lukas S. schrieb: > Ich mein in der rc.local und aufpassen, dass es vor dem exit 0 ist. Ja, steht vor exit 0. Ich starte ja auch andere Dinge (fancontrol, input-event-daemon usw.) ohne Probleme über rc.local. Und wenn ich den Eintrag für das Skript - so wie er in rc.local steht - kopiere und auf der konsole einfüge dann startet das Skript auch. Aber warum nicht automatisch über rc.local?
> Aber warum nicht automatisch über rc.local?
Vielleicht fehlt es an Eintraegen fuer den Suchpfad aka PATH.
Gib einfach den ganzen Pfadnamen an.
Im Skript vielleicht auch. Spart Aerger.
Daran liegt es auch nicht, habe mal die kompletten Pfade mit reingenommen.
Ein paar Dinge du zum Debuggen versuchen kannst: - Trage in die rc.local vor und nach dem Aufruf den logger ein um beim Booten eine Art Debug-Ausgabe zu bekommen - steht dann in /var/log/messages.
1 | logger "vor aufruf" |
2 | aufruf von hdparm |
3 | logger "nach aufruf" |
- Ausgabe von hdparm in Datei leiten - vielleicht gibt's ja eine Sinnvolle Fehlermeldung. Natürlich stdout UND stderr. hdparm -bla /dev/xxx &> /pfad/mit/schreibrechten/hdparm-log.txt - Rufe ein extra Script auf, das das mit dem hdparm in die Hand nimmt. - Vielleicht macht dein System auch was mit der Plattenverwaltung, Standby, ... Du kannst z.B. durch die init-scripte greppen und findest dort was. Obwohl rc.local normalerweise als allerletztes ausgeführt wird, passiert da vielleicht doch noch was anderes.
1 | [/etc/init.d] $ grep hdparm * |
Danke für die Hinweise, aber ich rufe hdparm ja nun nicht mehr direkt auf in der rc.local. Stattdessen verwende ich dieses Skript: http://linuxwiki.de/hdparm#disk_spindown.sh Im Kommentar ist auch erwähnt, dass die üblichen Parameter -B und -S bei den WD Green Platten nicht funktionieren. Das ist auch definitiv so, die Fehlermeldungen habe ich ja weiter oben schon gepostet. Die Platte unmittelbar mit -y in den Standby zwingen funktioniert. Und das macht das Skript ja (das an sich auch funktioniert). Aber leider nicht über rc.local startet.
Hallo, wenn auch spät - hier eine Möglichkeit, die zumindest bei mir dieses Problem verursacht hatte: Du musst darauf achten, dass du die UUID der Festplatte und nicht die PARTUUID der Partition verwendest. Wenn du z. B. "blkid" aufrufst, wird beides angezeigt. Die PARTUUID steht hinten und ich habe sie versehentlich zunächst genommen. UUID steht vorne. Ruft man den Befehl manuell mit "hdparm -C /dev/sdX" auf, tuts komischerweise auch die PARTUUID. Aber im automatischen Modus nicht. Viele Grüße Eric
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.