[Workaround] 'hdparm -S' funktioniert nicht (PowerManagement)

[Gräfin Klara]

Sporadisch wachen sie auf, ohne dass mir klar ist, warum das so ist.
Manchmal schalten sie sich schlicht gar nicht ab, und ich muss das manuell triggern. Dann bleiben sie auch aus.
Ich habe hierzu noch kein Muster herausfinden können...

Weil sie mapped sind. Sei es weil verschlüsselt, LVM oder aus anderen Gründen.
D.h. der Kernel sitzt dazwischen und kommuniziert (ohne dein Zutun) sporadisch und aus vielen Gründen über das mapping mit der Platte.
Dann wacht sie auf oder schaltet nicht ab. Diesen Umstand werden auch die neuen Platten nicht ändern.
Löse es mit cron. Sag dem Kernel "nun ist Schluss", danach hdparm und umgekehrt beim Aufwecken.
Anders wird es mit hoher Wahrscheinlichkeit nie zuverlässig funktionieren.

Gruß
Gräfin Klara

 

[Christina]

Zu einem großen Anteil (circa 70 bis 90 Prozent) schalten die Platten sich wie gewünscht ab. Nicht in der von mir gedachten Zeit, aber sie tun es.
Sporadisch wachen sie auf, ohne dass mir klar ist, warum das so ist.
Manchmal schalten sie sich schlicht gar nicht ab, und ich muss das manuell triggern. Dann bleiben sie auch aus.

Ich kann nur zu openSUSE berichten: Zu 70%—90% schaltet die HDD exakt mit der vorgegebenen Zeit ab.
Manchmal schaltet die HDD nach dem Aufwachen aus Suspend auch nach 2 Stunden nicht ab; dann genügt aber ein kurzer Dateizugriff, anschließend schaltet die HDD exakt wie gewünscht ab.

Seltsam in Leap 15.2:
Beim Mounten / Unmounten (per Dateimanager oder udisksctl) eines beliebigen USB-Laufwerks wird immer die interne HDD aufgeweckt, also aus dem Suspend geholt; egal ob unter Gnome oder XFCE.
In Leap 15.1 gab es das nicht.

 

[gehrke]

Bei mir haben sich die Fragezeichen auf der Stirn im Laufe der Zeit eher vermehrt als verringert.
Bei ansonsten gleichbleibender Software tausche ich im monatlichen Wechsel die Festplatten - 2 Disks jeden Monat, insgesamt 2 Sätze.

Der eine Satz hält sich mehrheitlich an meine Vorgaben, dem anderen scheinen sie komplett egal zu sein. Die tanzen mir auf der Nase rum...

 

[gehrke]

Die tanzen mir auf der Nase rum...

Jetzt ist Schluss mit lustig!

Sporadisch wachen sie auf, ohne dass mir klar ist, warum das so ist.
Manchmal schalten sie sich schlicht gar nicht ab, und ich muss das manuell triggern. Dann bleiben sie auch aus.
Ich habe hierzu noch kein Muster herausfinden können...

Weil sie mapped sind. Sei es weil verschlüsselt, LVM oder aus anderen Gründen.
D.h. der Kernel sitzt dazwischen und kommuniziert (ohne dein Zutun) sporadisch und aus vielen Gründen über das mapping mit der Platte.

Ich glaube nicht, dass Du hier Recht hast. Keine Komponente des OS greift darauf zu, lediglich wenn der Bacula-Director dies anordnet. Das sehe ich anhand des Job-Schedulings - es ist immer ein Bacula-Job, der für das Anspringen sorgt.

Löse es mit cron. Sag dem Kernel "nun ist Schluss", danach hdparm und umgekehrt beim Aufwecken.
Anders wird es mit hoher Wahrscheinlichkeit nie zuverlässig funktionieren.

Ich habe jetzt einen cron-job ausschließlich für das Suspend, Wake-up geht automatisch. Die gesamte LVM/LUKS-Kette kann unverändert bleiben, so dass ich keine Credentials speichern muss.

Script hierzu:

#!/bin/sh

# suspend disks if no backup jobs running

source ./functions

disk=`get_backup_disk_private`
echo "check for suspending disk: $disk"
echo "status director" | /usr/sbin/bconsole | grep -v 'w520' | grep 'is running'
if [ $? -eq 0 ]
then
  echo "running jobs on backup disk 'private' - do nothing"
else
  /usr/sbin/smartctl -i -n standby "$disk" | grep 'STANDBY'
  if [ $? -ne 0 ]
  then
    echo "no backup jobs on backup disk 'private' and disk online - suspend disk $disk"
    /usr/sbin/hdparm -y "$disk"
  fi
fi

disk=`get_backup_disk_work`
echo "check for suspending disk: $disk"
echo "status director" | /usr/sbin/bconsole | grep 'is running' | grep 'w520'
if [ $? -eq 0 ]
then
  echo "runnig jobs on backup disk 'work' - do nothing"
else
  /usr/sbin/smartctl -i -n standby "$disk" | grep 'STANDBY'
  if [ $? -ne 0 ]
  then
    echo "no backup jobs on backup disk 'work' and disk online - suspend disk $disk"
    /usr/sbin/hdparm -y "$disk"
  fi
fi

# crontab -l
*/10 * * * * date >> /var/log/disks-standby.log ; cd /root/projects/local; ./suspendDisks.sh >> /var/log/disks-standby.log

Nochmal zum Hintergrund: Ich arbeite mit 2x2 Festplatten im monatlichen Wechsel, jeweils eine für die privaten Daten und eine andere für den Job. Welches Device hier verwendet werden soll, ergibt sich aus den trivialen Funktionen in 'functions', welche ich hier nicht veröffentliche.

Vielleicht hilft es aber trotzdem jemanden. Es läuft jetzt jedenfalls seit einigen Tagen zuverlässig und ich werde hoffentlich meinem Konto und dem Klima damit einigen unnötigen Stromverbrauch ersparen.

Ich find's nur sehr schade, dass das PowerManagement der Platten selbst hier nicht verlässlich funktioniert, so dass man zu solchen Sonderlocken verdammt ist.

 

[Gräfin Klara]

Ich glaube nicht, dass Du hier Recht hast. Keine Komponente des OS greift ...

ok.
Wir haben LVM/Raid/LUKS. Dann wird es wohl das Raid sein.

Es läuft jetzt jedenfalls seit einigen Tagen zuverlässig ...

Bin neugierig, ob das so bleibt.

 

[gehrke]

Wir haben LVM/Raid/LUKS. Dann wird es wohl das Raid sein.

Sorry - ich merke gerade, dass ich mich falsch ausgedrückt habe:

Die gesamte LVM/LUKS-Kette kann unverändert bleiben, so dass ich keine Credentials speichern muss.

LVM ist bei mir ebenfalls nicht im Spiel. Zwar ist die SSD für das OS mit LVM partitioniert, aber die beiden Backup-Disks sind herkömlich ohne LVM partitioniert. Da ist also nur LUKS.