Stündliche Zugriffe verhindern Einschlafen der HDDs

[Creideiki]

Hallo,

ich fand es klasse, dass es jetzt eine Spin-Down-Einstellung gibt, der dafür sorgt, dass die Platten schlafen gehen, wenn niemand zugreift.

Als ich die Stromaufnahme gemessen habe, habe ich aber festgestellt, dass mein RN102 pünktlich jede Stunde die Platten wieder hochfährt, was die Sache etwas ad absurdum führt.

Die Frage ist nun: Wer greift darauf zu?

Ich habe dafür gesorgt, dass kein Client darauf zugegriffen hat und auch per NFS nichts gemounted war. Das hat nichts gebracht. Dann habe ich mal den Netzwerkstecker gezogen; daraufhin hat er nicht mehr regelmäßig zur vollen Stunde zugegriffen, sondern etwas unregelmäßiger. Diese Zugriffe konnte ich darauf zurückführen, dass das ReadyNAS erfolglos versucht hat, den NUT-Server zu erreichen und diese Tatsache ins Logfile geschrieben hat.

Ich weiß aber immer noch nicht, wer die Zugriffe erzeugt. Wie kriege ich das am Besten raus?

[EskenderNG]

Hallo,

ich weiss nicht ob man den Verursacher direkt in den Logs identifizieren kann. Wenn ich mir andere Threads zu dem Thema anschaue scheinen die häufigsten Verursacher WOL, Addons, iSCSI und mysql zu sein. Wobei eine Verbesserung durch entfernen des Netzwerkkabels die Liste einschränkt. Hier sind zwei Threads mit potentieller Lösung:

viewtopic.php?f=24&t=78789
viewtopic.php?f=154&t=77842

Gruß,
Eskender

[Creideiki]

Vielen Dank für die schnelle Antwort. Ich war eigentlich der Meinung, dass ich schon recht ausführlich gesucht hätte; aber ich hatte offensichtlich nicht das richtige Stichwort.

Ich habe folgendes gemacht (kurz vor der vollen Stunde):

echo 1 > /proc/sys/vm/block_dump

und kurz danach

echo 0 > /proc/sys/vm/block_dump
journalctl -a

Dabei kam u.a. heraus:

Mar 12 09:00:35 Haoke kernel: ntpd(1187): dirtied inode 2158 (ntp.drift.TEMP) on md0
Mar 12 09:00:35 Haoke kernel: ntpd(1187): dirtied inode 2158 (ntp.drift.TEMP) on md0
Mar 12 09:00:35 Haoke kernel: ntpd(1187): WRITE block 312744 on md0 (8 sectors)
Mar 12 09:00:35 Haoke kernel: md0_raid1(676): WRITE block 8 on sda1 (1 sectors)
Mar 12 09:00:35 Haoke kernel: md0_raid1(676): WRITE block 8 on sdb1 (1 sectors)
Mar 12 09:00:35 Haoke kernel: ntpd(1187): dirtied inode 2224 (?) on md0
Mar 12 09:00:35 Haoke kernel: md0_raid1(676): WRITE block 8 on sda1 (1 sectors)
Mar 12 09:00:35 Haoke kernel: md0_raid1(676): WRITE block 8 on sdb1 (1 sectors)

Soso, ntp shreibt da also was. Ein bißchen genauere Suche im Netz (und obige Dateiangabe) zeigte dann, dass ntp sich nicht so gut mit heruntergefahrenen Festplatten verträgt. Insbesondere das Drift-File ist hier interessant. Auszug aus der Manpage zu ntp.conf:

driftfile driftfile
              This  command  specifies  the name of the file use to record the frequency offset of the local clock oscillator.  If the file exists, it is read at startup in order to set the initial frequency offset and then updated
              once per hour with the current frequency offset computed by the daemon.  If the file does not exist or this command is not given, the initial frequency offset is assumed to be zero.  In this case,  it  may  take  some
              hours for the frequency to stabilize and the residual timing errors to subside.

              The  file  format  consists  of  a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM).  The file is updated by first writing the current drift
              value into a temporary file and then renaming this file to replace the old version.  This implies that ntpd must have write permission for the directory the drift file is located in, and that file system  links,  sym‐
              bolic or otherwise, should be avoided.

Der zweite Absatz verrät das Problem. ntp schreibt nicht nur in die Datei, sondern es legt eine neue an und benennt die dann um. Das funktioniert offensichtlich nicht mehr nur im Schreibcache und damit muß das NAS die Platten hochfahren.

Lösung
Auch wenn es ein bißchen Nachteile hat, habe ich in der ntp.conf den driftfile-Eintrag auskommentiert und den ntp neu gestartet. Jetzt scheint Ruhe zu sein.