hdparm -S keine Änderung

[lordg2009]

Hi,

seit mehreren Jahren stelle ich meine WD Red Platten mit hdparm -S auf eine standby Zeit von 30 min ein. Es gab wohl einzelne Platten, welche von Bugs betroffen waren, so dass sie sich andauernd selbst gestartet und gestoppt haben. Außerdem schaue ich darüber größtenteils Filme, wenn Zugriff auf eine solche Platte stattfindet, soll sie gleich anbleiben, sonst halt nicht. Ich fahre damit sehr gut, bis jetzt ist mir noch keine Platte abgerauscht, obwohl der Server 24/7 läuft. Seitdem ich von debian 7 auf 8 geupdatet habe, funktioniert aber die Konfiguration nicht mehr. Gebe ich 'hdparm -S 241' (für standby nach 30 min) ein und schaue nach 40 minuten nach mit hdparm -C, so sind alle Platten noch im active/idle, nicht aber wie früher im standby. Hat das was mit dem Update zu tune, ich kanns mir nicht erklären. Wenn hdprm -S 241 aufgerufen wurde, steht auch da, dass die standby Zeit angepasst wird.

Vielen Dank für eure Hilfe

 

[Piktogramm]

Hast du mal getestet, ob hdparm -y überhaupt dazu führt, dass das entsprechende Laufwerk in den Standbye geht und dort auch bleibt? Wenn das Laufwerk kurzfristig wieder geweckt wird gibt es schlicht Zugriffe, die den gesetzten Timer immer wieder zurücksetzen.

 

[lordg2009]

Guter Einwand, ich habe mal ein wenig nachgeforscht:

hdparm -y funktioniert, die entsprechende Platte ist dann im standby
hdparm -S funktioniert aber nicht (testweise auf 5s -> keine Platte wechselt in den standby)

ich habe mit

echo 1 > /proc/sys/vm/block_dump

alle plattenzugriffe protokollieren lassen und mir per

tail -f /var/log/kern.log | grep -v 'systemplatte'

anzeigen lassen

Resultat:
keine Plattenzugriffe auf die entsprechenden platten

die manuell in den standby gesetzte platte bleibt auch im standby, bis sie geweckt wird

hdparm -S funktioniert nicht mehr

Woran kann das liegen?

 

[Piktogramm]

Wenn du hdparm -S mit Rootberechtigung manuell ausführst und das nicht wirkt, dann würde ich anfangen mit Suchen, vor allem englischsprachigem Linux Communities. Was ich gefunden habe ist, dass ext4 lazy init (https://www.thomas-krenn.com/de/wiki/Ext4_Dateisystem#Lazy_Initialization) als Grund häufiger auftaucht.

Wenn du hdparm -S im Init-Prozess hängen hast. Debian hat systemd mit Debian 8 eingeführt, Anpassungen des Init-Prozesses müssen entsprechend angepasst werden.

 

[lordg2009]

Hdparm hängt bei mir nicht im init. Ich habe ein kleines script, welches hdparm -S für jede Platte einzeln ausführt und zwar mit root rechten. Aber der Befehl klappt nicht. Vlt kann ich einen downgrade durchführen und schauen, ob das was bewirkt.

 

[Piktogramm]

Das Downgrade ist aber eher ein Behandeln der Symptome als der Ursache. hdparm -S scheint in der Masse keine Probleme zu machen, entsprechend ist es wahrscheinlich, dass der Fehler irgendwo bei dir in der Config hängt.

Also nochmal, hdparm -S bei manuellem Aufruf bewirkt auch nichts? Da würde ich noch kontrollieren, ob der Sata Controller im AHCI Modus ist und ansonten eine englischsprachige Debiancommunity bemühen.

Wenn hdparm -S funktioniert und die Scripte nicht, dann gehe ich davon aus, dass sie automatisch aufgerufen werden und entsprechend ist da die Ursache, dass hier systemd etwas anders tickt.

 

[lordg2009]

Sata ist im BIOS im AHCI Modus eingestellt.
hdparm -S manuell bewirkt nichts, hdparm -y dagegen schon
Habe noch ein bisschen gelesen, merkwürdigerweise ergibt dmesg | grep -i ahci, scsi, oder sata keinerlei ergebnisse.
Wenn man hdparm im verbose modus nutzt sieht man ja den output, der übermittelt wird, kann das jemand lesen, wenn ich das poste.
Ich habe noch nie eine englische debian community kontaktiert, wo muss ich mich melden?