[3. Sammelthema] Probleme mit Festplatten-Standby

Ich habe mal eine Log-Datei erstellt, wenn das Gerät nicht mit der Fritzbox verbunden ist. Die Festplatten schlafen jetzt zwar deutlich länger, werden aber immer noch ohne äußeres zutun aufgeweckt.

Mag mal jemand einen weiteren Blick darauf werfen?

Nachdem ich nun die aktuellste Firmware installiert und praktisch fast alles an Features deaktiviert habe, bleibt die Festplatte jetzt die meiste Zeit im Standby.

Mir ist jedoch aufgefallen, dass (auch bei unterbrochener LAN-Verbindung) die Festplatten jeden Tag zur gleichen Zeit trotzdem offenbar durch irgendeinen Prozess geweckt werden.

Gibt der angehängte Log da vielleicht irgendwelche Hinweise, warum die immer zur gleichen Zeit passiert? Da scheint es ja ein System hinter zu geben...

Seltsam, ich scheine den Auslöser einfach nicht finden zu können. :-/

Die LAN Verbindung zur Fritzbox ist unterbrochen, sämtliche Dienste habe ich nach Möglichkeit deaktiviert.

Trotzdem werden die Festplatten jeden Abend gegen 20:02 hochgefahren und gehen um 20:17 wieder in den Standby. Die Festplatten sind so eingestellt, dass sie vom NAS nach 10 Minuten Inaktivität in den Standby versetzt werden sollen.

Demnach scheint also irgendwas intern für ungefähr 5 Minuten auf die Festplatten zuzugreifen.

Aber auch in der crontab konnte ich keinen Eintrag finden, der auf irgendeinen passenden Prozess hindeuten würde:

# m h dom m dow cmd
0 2 * * * /sbin/qfstrim
0 3 * * 0 /etc/init.d/idmap.sh dump
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
0-59/15 * * * * /etc/init.d/nss2_dusg.sh
30 7 * * * /sbin/clean_upload_file
30 3 * * * /sbin/notice_log_tool -v -R
10 15 * * * /usr/bin/power_clean -c 2>/dev/null
*/10 * * * * /sbin/config_cache_util 0
0 9,21 * * * /sbin/notify_update -m -s -p 1>/dev/null 2>&1
* * * * * /var/cache/netmgr/lock_timer.sh
* * * * * /var/cache/netmgr/detect_defaultgw_internet.sh
4 3 * * 3 /etc/init.d/backup_conf.sh
53 21 * * * /mnt/ext/opt/QcloudSSLCertificate/bin/ssl_agent_cli
~
~
~
~
~
~
crontab                                                      [100%]  16,01

EDIT: Das ganze Spiel wiederholt sich dann noch mal um (ungefähr) 20:32 und 21:53. Danach ist dann offenbar bis zum nächsten Abend Ruhe.

Was stört dich an diesem einen Zugriff auf die Platten?
Du wirst es eh nicht erreichen, dass die Platten 24h schlafen, es sei denn du schaltest das NAS aus.

Prinzipiell habe ich hauptsächlich ein Problem mit der Uhrzeit (zwischen 20 und 22 Uhr), zu denen die Festplatten immer anspringen.

Da es ja offenbar irgendwie durch einen Timer gesteuert wird, würde ich zumindest gerne selbst bestimmten, zu welcher Uhrzeit es passiert. Damit könnte ich dann die nervigen Geräusche von den Festplatten so verschieben, dass ich nicht zu Hause bin.

Ich hatte das HS-251+ NAS explizit wegen der lüfterlosen Bauweise gekauft, weil ich in meiner kleinen Wohnung nicht viele Aufstellmöglichkeiten habe und das Gerät deshalb im Wohnzimmer stehen muss.

Habe zu meinem Problem eine Anfrage vom Qnap Support erhalten.

Ich soll für den Zeitraum mit einem blk_temp Log zusätzliche Informationen sammeln. Leider konnte ich aber keine Informationen darüber finden, wo ich diesen Log erstellen lassen kann. Im Diagnostic Tool konnte ich keinen passenden Eintrag finden.

Außerdem, wenn ich über ssh auf das Gerät zugreife und die Befehle top oder ps benutzen möchte. Kann ich da einen Zeitraum definieren und alle Einträge in ein Log schreiben lassen? Oder bekomme ich mit den beiden Befehlen immer nur eine Momentaufnahme?

Zitat von TOMillr

Leider konnte ich aber keine Informationen darüber finden, wo ich diesen Log erstellen lassen kann.

Du outest dich damit, dass du die Überschrift dieses Themas nicht gelesen oder nicht verstanden hast.
Andererseits hast du aber in deinen Beiträgen oben (241 und 242) jeweils schon ein solches Log gepostet. Das ist dann doch etwas verwirrend.

Hehe, ich hatte halt einfach im Diagnostic Tool irgendwo nach einem "blk_temp" Eintrag gesucht und nicht auf den Namen des eigentlichen Log-Files geachtet. Asche auf mein Haupt

Bei den ps und top Befehlen kann ich also nicht einen Zeitraum zum Bewachen bestimmen (sagen wir zum Beispiel 19:50 bis 20:10) und alle auftreten Prozesse und Aktivitäten in einen Log schreiben lassen?

Nein. Nicht so ohne weiteres. Bringt auch nichts, weil man ja die Prozesse wissen möchte, die zu dem Zeitpunkt auf die Platten zugreifen.

Hallo zusammen,

ich hoffe Ihr könnt mir helfen!

ich habe eine TS-869 Pro mit 8 Platten (2x RAID5 mit je vier Platten) mit der Firmware 4.3.3.0210 und die Festplatten gehen nicht in den Standby. Das Log vom blkdevMonitor mit 100 Durchläufen habe ich angehängt.

Könnt Ihr mir sagen, welcher Prozess meine Platten wach hält?

Vielen Dank im Voraus!
Thomas

Hallo Forengemeinde,

ich möchte nun auch meinen 'Senf' zu dem leidigen Thema StandBy bringen.

Kann es denn nicht sein, dass es bei einigen Postern sich um um gänzlich anderer Herkunft des Problems handelt ?

Folgendes zu den Wake-Up's. Ich habe selbst Platten der Firma WD und eigentlich ausschließlich diese. Hier gab es zu mindest bei den WD-Red der Generation wo 2 und 3 Terra aufkamen das Problem, dass die Firmware der Hdd's einen Bug hatte und damit die Platten andauernd im 6 sek Takt die Köpfe rein aus raus gefahren (Load-Cycle-Count) sind. Der Load-Cycle-Count war binnen Tagen auf über 300.000 Counts angewachsen, und die Platten wollten sich verabschieden.Abhilfe schaffte WD damals, dass es ein Tool herausgab, wo intern dieser Bug zumindest scheinbar behoben wurde. Belastete Hdd's der Red-Family wurden dann getauscht (i.d.R gegen 'refurbished'). Sind aber glaub ich höherwertig - denke Enterprise.

Also - es wäre mal hilfreich wenn die 'genervten User' mal mitteilen, um welche Hdd's es sich handelt.
Ich gehe nämlich davon mal aus dass ein gewisser Teil nicht Q-nap - spezifisch ist. Im übrigen lässt z.B. die Time-Sync mit NTP nicht unbedingt die Platten anlaufen.

Grüße
Tom63

Angeblich sollte die letzte Firmware-Version das Standby Problem beheben. Ich konnte bei mir jedoch keine Besserung feststellen - die Festplatten bleiben sogar länger aktiv als bei der letzten Firmware.

Die Festplatten springen z.B. immer gegen 19:55 an und bleiben dann für genau eine halbe Stunde aktiv. Da ich für den HDD Standby ein Intervall von 10 Minuten eingestellt habe, muss also irgendwas auf Systemebene (ich habe weiterhin alles deaktiviert und die Netzwerkverbindung gesperrt) für 20 Minuten die Festplatten benutzen...

ich würde mal schauen, wo die folgenden Dateien liegen (find / -name datei):
site.pyc,os.pyc,posixpath.pyc,stat.pyc,warnings.pyc,linecache.pyc,types.pyc,UserDict.pyc

Auf diese (und weitere) wird kurz vor 20:00 zugegriffen. Über den pfad kommst du vielleicht an den Grund

Die Dateien liegen alle in diesem Ordner:

/mnt/ext/opt/Python/lib/python2.7/

schau mal obs einen Befehl oder eine datei "detect_defaultg" gibt (type detect_defaultg, find ...)

Evtl. get_mac_addr.sh

/mnt/ext/opt/netmgr/util/get_mac_addr.sh

"detect_defaultg" konnte ich hingegen nicht finden.

Hallo,

ich habe eine Problem mit dem Standby, ich habe das Script von Seite 1 verwendet und rausgefunden, dass der Cronjob /etc/init.d/storage_usage.sh Probleme macht.

Mein System:
TS-653B-4G
System-Volume im Raid1 mit SSDs (Container Station installiert und aktiviert mit einer virtuellen Maschine)
Data-Volume im Raid5 mit HDDs (Nur Daten, keine Apps)

Durch die VM geht die NAS natürlich nie komplett in den Standby, aber die HDDs schalten sich ab.

Problem: Sobald /etc/init.d/storage_usage.sh ausgeführt wird, gehen auch die HDDs wieder an.

Aktuelle Lösung: /etc/init.d/storage_usage.sh im Cronjob deaktiviert.

Ich kann auf meiner VM jetzt ohne Probleme arbeiten und die HDDs bleiben aus.

Frage: Braucht man /etc/init.d/storage_usage.sh? Weiß jemand genau was es tut? Irgendwas mit verbrauchen Speicher, dass mir schon klar, aber genauere Informationen wären super.

Ich bin für jede Hilfe dankbar.

Hallo, habe nach meinem Upgrade auf 4.3.3 mit meiner TS-119 PII mal wieder Probleme mit dem Standby. Habe in der Zwischenzeit rausgefunden, dass smbd auf Dateien unter /share/HDA_DATA/.samba/lock zugreift - auch wenn alle Rechner im Netz ausgeschalten sind. Das Unterverzeichnis msg.lock ist seit 4.3.3. als tmpfs gemountet - wahrscheinlich um ein Aufwachen der Platte zu verhindern.

Ich habe jetzt in einem ersten QuickFix einfach das gesamte Verzeichnis ../.samba/lock als tmpfs gemountet und die Samba Prozesse gekillt. Sieht nun besser aus.

Hat jemand ähnliche Probleme mit Samba gehabt?

Hallo,

ich habe ein neues TS-453A bei dem die Festplatten nicht in den StandBy gehen. Könntet Ihr mal drüber schauen wie sich das Problem lösen läßt. Es wird immer wieder in den gleichen Sektor geschrieben.

============= 31/100 test, Mon Aug 14 13:03:43 CEST 2017 ===============
<7>[328839.917422] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328839.917451] md1_raid5(8718): WRITE block 5840623504 on sdd3 (1 sectors)
<7>[328839.917465] md1_raid5(8718): WRITE block 5840623504 on sdc3 (1 sectors)
<7>[328839.917480] md1_raid5(8718): WRITE block 5840623504 on sdb3 (1 sectors)
<7>[328840.189264] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328840.189297] md1_raid5(8718): WRITE block 5840623504 on sdd3 (1 sectors)
<7>[328840.189311] md1_raid5(8718): WRITE block 5840623504 on sdc3 (1 sectors)
<7>[328840.189323] md1_raid5(8718): WRITE block 5840623504 on sdb3 (1 sectors)
<7>[328844.559330] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328839.917422] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328840.189264] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328844.559330] md1_raid5(8718): WRITE block 5840623504 on sda3 (1 sectors)
<7>[328839.917480] md1_raid5(8718): WRITE block 5840623504 on sdb3 (1 sectors)
<7>[328840.189323] md1_raid5(8718): WRITE block 5840623504 on sdb3 (1 sectors)
<7>[328839.917465] md1_raid5(8718): WRITE block 5840623504 on sdc3 (1 sectors)
<7>[328840.189311] md1_raid5(8718): WRITE block 5840623504 on sdc3 (1 sectors)
<7>[328839.917451] md1_raid5(8718): WRITE block 5840623504 on sdd3 (1 sectors)
<7>[328840.189297] md1_raid5(8718): WRITE block 5840623504 on sdd3 (1 sectors)


============= 32/100 test, Mon Aug 14 13:04:25 CEST 2017 ===============