NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

Creideiki's avatar
Creideiki
Aspirant
Mar 11, 2015

Stündliche Zugriffe verhindern Einschlafen der HDDs

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?

2 Replies

  • EskenderNG's avatar
    EskenderNG
    NETGEAR Employee Retired
    Mar 11, 2015
    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's avatar
    Creideiki
    Aspirant
    Mar 12, 2015
    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.

NETGEAR Academy

Steigern Sie Ihre Fähigkeiten mit der Netgear Academy - Lassen Sie sich schulen, zertifizieren und bleiben Sie mit der neuesten Netgear-Technologie auf dem neuesten Stand!

Machen Sie mit!

ProSupport for Business

Umfassende Supportpläne für maximale Netzwerkverfügbarkeit und geschäftliche Sicherheit

Mehr erfahren