[3. Sammelthema] Probleme mit Festplatten-Standby

bei dir sind es Zugriffe auf die qid_persistent.conf

Such mal danach
find / -name qid_persistent.conf

Gebe ich über ssh deinen Befehl ein, kommt folgendes.

[~] # find / -name qid_persistent.conf/mnt/HDA_ROOT/.config/qid_persistent.conf

Meine Crontab sieht so aus:

[~] # crontab -l
# m h dom m dow cmd
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
10 15 * * * /usr/bin/power_clean -c 2>/dev/null
30 7 * * * /sbin/clean_upload_file
0 2 * * * /sbin/qfstrim
0-59/10 * * * * /etc/init.d/storage_usage.sh
30 3 * * * /sbin/notice_log_tool -v -R
0 22 * * * /sbin/hal_app --led_brightness_in_night_mode enc_id=0,mode=1
0 6 * * * /sbin/hal_app --led_brightness_in_night_mode enc_id=0,mode=2
0 3 * * 0 /etc/init.d/idmap.sh dump
*/10 * * * * /sbin/config_cache_util 0
0 9,21 * * * /sbin/notify_update -m -s -p 1>/dev/null 2>&1
4 3 * * 3 /etc/init.d/backup_conf.sh
30 7 * * * /usr/local/sbin/version_cleaner -t 0 > /dev/null 2>/dev/null
* * * * * /mnt/ext/opt/netmgr/util/lock_timer.sh
35 7 * * * /sbin/qbox_util -c > /dev/null 2>/dev/null
26 14 * * * /share/CACHEDEV1_DATA/.qpkg/QcloudSSLCertificate/bin/ssl_agent_cli

Kann man die crontab "reduzieren", sodass manche unnötigen Sachen die NAS nicht wecken?

@TS-251-Flo
Welche FW-Version/Build? (Edit: laut Profil QTS 4.3.3.0136 Build 20170328 - also Beta)

Verursacher ist

<7>[ 4410.960113] setcfg(8295): dirtied inode 361 (qid_persistent.conf) on md9
<7>[ 4410.960179] setcfg(8295): dirtied inode 361 (qid_persistent.conf) on md9

Wozu die qid_persistent.conf gehört weiss ich im Moment leider nicht.

Ich habe mir wegen dem lüfterlosen Betrieb ein HS-251+ NAS und zwei WD Red 4TB zugelegt. Leider scheinen aber die beiden Festplatten ununterbrochen zu laufen und nicht in den Standby-Modus zu wechseln, wenn nicht auf das Gerät zugegriffen wird.

Verbunden ist das Gerät mit einem Ethernetkabel an eine Kabel-Fritzbox 6490. Außer dem Plex-Server habe ich sonst keine zusätzlichen Dienste auf dem NAS installiert.

Muss ich irgendwo noch eine Einstellung vornehmen, damit die Festplatten endlich Ruhe geben?

Ich habe jetzt auch mal das BulDevTool aus dem 1. Posting auf einem HS-251+ mit zwei WD Red 4TB laufen lassen. Abgesehen vom Plex Server habe ich keine zusätzlichen Dienste installiert.

[~] # cp /share/Public/blkdevMonitor.sh /root
[~] # chmod 766 /root/blkdevMonitor.sh
[~] # /root/blkdevMonitor.sh
===== Welcome to use blkdevMonitor_v2 on Wed Apr 19 19:54:24 CEST 2017 =====
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1 
Start...
============= 0/100 test, Wed Apr 19 19:55:10 CEST 2017 ===============
<7>[81329.967518] kjournald(2098): WRITE block 557680 on md9 (8 sectors)
<7>[81329.967557] md9_raid1(2087): WRITE block 1060216 on sdb1 (1 sectors)
<7>[81329.967590] md9_raid1(2087): WRITE block 1060216 on sda1 (1 sectors)
<7>[81329.982787] md9_raid1(2087): WRITE block 1060232 on sdb1 (1 sectors)
<7>[81329.982807] md9_raid1(2087): WRITE block 1060232 on sda1 (1 sectors)
<7>[81330.005106] kjournald(2098): WRITE block 557688 on md9 (8 sectors)
<7>[81330.005121] kjournald(2098): WRITE block 557696 on md9 (8 sectors)
<7>[81330.005134] kjournald(2098): WRITE block 557704 on md9 (8 sectors)
<7>[81330.005147] kjournald(2098): WRITE block 557712 on md9 (8 sectors)
<7>[81330.005161] kjournald(2098): WRITE block 557720 on md9 (8 sectors)
<7>[81330.005174] kjournald(2098): WRITE block 557728 on md9 (8 sectors)
<7>[81330.005186] kjournald(2098): WRITE block 557736 on md9 (8 sectors)
<7>[81330.005198] kjournald(2098): WRITE block 557744 on md9 (8 sectors)
<7>[81330.005554] kjournald(2098): WRITE block 557752 on md9 (8 sectors)
<7>[81330.221972] md9_raid1(2087): WRITE block 1060216 on sdb1 (1 sectors)
<7>[81330.221997] md9_raid1(2087): WRITE block 1060216 on sda1 (1 sectors)
<7>[81330.238836] md9_raid1(2087): WRITE block 1060232 on sdb1 (1 sectors)
<7>[81330.238854] md9_raid1(2087): WRITE block 1060232 on sda1 (1 sectors)
<7>[81335.031378] kworker/u8:4(1560): WRITE block 0 on md9 (8 sectors)
<7>[81335.031415] md9_raid1(2087): WRITE block 1060216 on sdb1 (1 sectors)
<7>[81335.031449] md9_raid1(2087): WRITE block 1060216 on sda1 (1 sectors)
<7>[81335.070493] md9_raid1(2087): WRITE block 1060232 on sdb1 (1 sectors)
<7>[81335.070512] md9_raid1(2087): WRITE block 1060232 on sda1 (1 sectors)
<7>[81335.092830] kworker/u8:4(1560): WRITE block 8 on md9 (8 sectors)
<7>[81335.092851] kworker/u8:4(1560): WRITE block 524288 on md9 (8 sectors)
<7>[81335.092868] kworker/u8:4(1560): WRITE block 524296 on md9 (8 sectors)
<7>[81335.092884] kworker/u8:4(1560): WRITE block 524584 on md9 (8 sectors)
<7>[81335.092899] kworker/u8:4(1560): WRITE block 524592 on md9 (8 sectors)
<7>[81335.092914] kworker/u8:4(1560): WRITE block 524624 on md9 (8 sectors)
<7>[81335.092930] kworker/u8:4(1560): WRITE block 704832 on md9 (8 sectors)
<7>[81335.293875] md9_raid1(2087): WRITE block 1060216 on sdb1 (1 sectors)
<7>[81335.293902] md9_raid1(2087): WRITE block 1060216 on sda1 (1 sectors)
<7>[81335.315416] md9_raid1(2087): WRITE block 1060232 on sdb1 (1 sectors)
<7>[81335.315435] md9_raid1(2087): WRITE block 1060232 on sda1 (1 sectors)
<7>[81332.949378] md1_raid1(3410): WRITE block 7794127504 on sdb3 (1 sectors)
<7>[81332.949412] md1_raid1(3410): WRITE block 7794127504 on sda3 (1 sectors)
<7>[81333.222829] md1_raid1(3410): WRITE block 7794127504 on sdb3 (1 sectors)
============= 1/100 test, Wed Apr 19 19:56:19 CEST 2017 ===============
<7>[81449.257839] setcfg(30743): dirtied inode 13478 (qid_persistent.conf) on md9
<7>[81449.257903] setcfg(30743): dirtied inode 13478 (qid_persistent.conf) on md9
<7>[81455.204063] kjournald(2098): WRITE block 557760 on md9 (8 sectors)
<7>[81455.204106] md9_raid1(2087): WRITE block 1060216 on sdb1 (1 sectors)
<7>[81455.204137] md9_raid1(2087): WRITE block 1060216 on sda1 (1 sectors)

Mag mal jemand vielleicht einen Blick darauf werfen?

und wieder...log zu kurz...bitte komplett durchlaufen lassen und als txt-datei anhängen.

Seit der 4.2.3 lässt sich das script auch über das qts starten (qnap diagnostic tool - hdd analyse - test standby).

Zitat von TOMillr

Außer dem Plex-Server habe ich sonst keine zusätzlichen Dienste auf dem NAS installiert.

Ist sehr wahrscheinlich der Plex Server:
https://forums.plex.tv/discussion/135959

So, anbei dann mal der vollständige Log.

Schon mal Plex deaktiviert? Das taucht ja häufig in den Logs auf und wie oben verlinkt, ist es ein bekanntes Problem, dass die Festplatten dann nicht mehr schlafen gehen.

Hatte das Problem auch mit plex. Hab dem Ordner die Rechte 777 gesetzt und jetzt ist Ruhe. Scheinbar versucht plex was zu erstellen, aber die Rechte fehlen...

Kannst du mir genauer erklären, was du angestellt hast? Welchen Ordner meinst du denn?

Hallo,
ich sehe und höre auf meiner 453A Plattenaktivität seit ich sie neu bekommen habe. Ich konnte bisher nicht herausfinden woher die kommt. Der
Resourcenmonitor zeigt, dass da irgendetwas geschrieben wird. Bei den Prozessen erkenn ich auch nichts Besonderes. Inzwischen habe ich alles abgeschaltet, was machbar ist. Aktive Dienste sind nur noch Microsoft-Netzwerk und FTP.

Die ersten beiden Platten in Raid 1. Aktivität bei allen 4 Platten ist im vermeintlichen Leerlauf exakt gleich.

Hat jemand einen Tipp?

Zitat von UpSpin

Schon mal Plex deaktiviert? Das taucht ja häufig in den Logs auf und wie oben verlinkt, ist es ein bekanntes Problem, dass die Festplatten dann nicht mehr schlafen gehen.

Habe Plex testweise mal deaktiviert und den Test noch mal laufen lassen. Die Festplatten gehen aber leider trotzdem nicht nach den eingestellten 15 Minuten in den Standby.

in deiner log steht sehr häufig die cloudconnector-debug.log...suche die mal mit find / -name cloudconnector-debug.log

Wie komme ich denn daran? Über SSH?

Ich habe jetzt mal zum Test sowohl Plex als auch Hybrid Backup Sync - Beta deaktiviert. Leider gehen die Festplatten aber auch weiterhin nicht nach 15 Minuten in den Standby. Anbei ein aktualisierter Log.

siehst ja selbst, dass da ganz viel läuft, der Virenscanner zum Beispiel (freshclam) und vs_refresh (" vs_refresh is for share folder space usage calculation (for Network Share Management)")

Vermutlich hast du kurz davor größere Datenmengen drauf geschoben oder sonst irgendetwas verändert? Vielleicht weis jemand anderes wodruch vs_refresh verursacht wird.

Funktioniert der HDD Standby weiterhin nicht, oder sind sie vielleicht doch noch aus gegangen, nachdem du längere Zeit nichts mehr daran gemacht hast?

Zitat von UpSpin

Vielleicht weis jemand anderes wodruch vs_refresh verursacht wird.

Das wird nachts 3.00Uhr durch einen Cron-Job gestartet.

Naja, ich habe das Gerät recht neu und bislang eigentlich noch nie wirklich benutzt. Ich habe bislang den NAS immer wieder komplett ausgeschaltet, weil auch nach mehreren Tagen Dauerlauf die Festplatten nicht in den Standby gegangen sind.

Werde aber mal den Virenscanner zum Test ausschalten und sehen was passiert. Wieso läuft der überhaupt die ganze Zeit? Überprüft der Scanner denn kontinuierlich die Dateien? Oder dauert es nur beim ersten Mal lange, weil so viele Daten auf den Festplatten sind - und danach werden in Zukunft nur noch neue Dateien geprüft?

Hier noch schnell der Log mit ausgeschaltetem Virenscanner.

Hallo,

seit dem Update auf 4.3.3. gehen die Festplatten nicht mehr in den Standby, vorher hat es tadellos geklappt.
Ich habe schon mal diverse Apps deaktiviert (auch DLNA-Server und Medienbibliothek), alle Netzlaufwerke getrennt, Qsync deaktiviert aber es geht trotzdem nicht.

Könnte sich jemand, der was davon versteht, die log-Datei ansehen und mir nen Tipp geben, was es sein kann?

Danke und Gruß

@Laribum
Hauptsächlich:

<7>[144554.905566] python(15764): dirtied inode 6259075 (cloudconnector-debug.log) on dm-0