Merkwürdig ist bei dir, dass alleine der Start des Tools schon fast eine halbe Stunde benötigt.
Ist die Anzeige denn immernoch leer?
Merkwürdig ist bei dir, dass alleine der Start des Tools schon fast eine halbe Stunde benötigt.
Ist die Anzeige denn immernoch leer?
Hab das ganze ca. 20 Minuten weiterlaufen lassen. Keine Reaktion. Am Windowsrechner funktioniert die Problem-HD so wie sie soll. Hab das ganze Nas nun ohne die HD neu aufgesetzt.
Die HD die an Port 2 hing, ist nun auf Port 1 als Einzellaufwerk. Zuvor war ja JBOD eingerichtet.
Ergebnis: Standby Funktioniert einwandfrei.
Schon seltsam. Entweder kommt die NAS mit der ProblemHD nicht zurecht oder es liegt an JBOD, was ich mir aber nicht vorstellen kann.
Edit: so jetzt laufen beide und wieder das gleiche Problem. Zum verrückt werden.
Genaue Bezeichnung der Festplatten?
Nachdem ich auf 4.2.2 gewechselt habe und den workaround implementiert hatte, funktioniert der Spindown der Platten wieder Ordnungsgemäß.
Leider werden die Platten immer wieder aufgeweckt, obwohl auf das NAS nicht zugegriffen wird. Weder lokal noch remote.
Meine Samba-shares mounte ich nur bei Bedarf. An Diensten läuft auf dem NAS nur Samba, rsync (brauch ich nicht, finde aber keine Option zum ausschalten) und HDisplay mit KODI mit UPNP (läuft immer).
Nun habe ich mal das Script laufen lassen und soweit ich feststellen konnte weckt der Prozess language invoker die Platten immer auf.
============= 13/100 test, Tue Nov 29 09:48:46 CET 2016 ===============
READ block 3567512712 on dm-0 (8 sectors)
<7>[386997.603650] LanguageInvoker(3672): READ block 3567555256 on dm-0 (8 sectors)
<7>[386997.603732] LanguageInvoker(3672): READ block 3567555272 on dm-0 (8 sectors)
<7>[386997.604369] LanguageInvoker(3672): READ block 3567507592 on dm-0 (8 sectors)
<7>[386997.607304] LanguageInvoker(3672): READ block 3567557600 on dm-0 (8 sectors)
<7>[386997.607849] LanguageInvoker(3672): READ block 3567510920 on dm-0 (8 sectors)
<7>[386997.611038] LanguageInvoker(3672): READ block 3567506384 on dm-0 (8 sectors)
<7>[386997.612698] LanguageInvoker(3672): READ block 3567513168 on dm-0 (8 sectors)
<7>[386997.614568] LanguageInvoker(3672): READ block 3567509384 on dm-0 (8 sectors)
<7>[386997.616391] LanguageInvoker(3672): READ block 3567511312 on dm-0 (8 sectors)
<7>[386997.618206] LanguageInvoker(3672): READ block 3567511568 on dm-0 (8 sectors)
<7>[386999.755557] LanguageInvoker(3672): READ block 3567555552 on dm-0 (8 sectors)
<7>[386999.757929] LanguageInvoker(3672): READ block 3567557544 on dm-0 (8 secto rs)
<7>[386999.759283] LanguageInvoker(3672): READ block 3567557064 on dm-0 (8 sectors)
<7>[386999.762480] LanguageInvoker(3672): READ block 3567555672 on dm-0 (8 sectors)
<7>[386999.763791] LanguageInvoker(3672): READ block 3567554728 on dm-0 (8 sectors)
<7>[386999.766092] LanguageInvoker(3672): READ block 3567554472 on dm-0 (8 sectors)
<7>[386999.780383] LanguageInvoker(3672): READ block 3567554352 on dm-0 (8 sectors)
<7>[386999.781808] LanguageInvoker(3672): READ block 3567556632 on dm-0 (8 sectors)
<7>[386999.783043] LanguageInvoker(3672): READ block 3567554672 on dm-0 (8 sectors)
<7>[386999.784237] LanguageInvoker(3672): READ block 3567555480 on dm-0 (8 sectors)
<7>[386999.785773] LanguageInvoker(3672): READ block 3567555560 on dm-0 (8 sectors)
<7>[386999.785844] LanguageInvoker(3672): READ block 3567555576 on dm-0 (8 sectors)
<7>[386999.786983] LanguageInvoker(3672): READ block 3567555816 on dm-0 (8 sectors)
<7>[386999.788171] LanguageInvoker(3672): READ block 3567556384 on dm-0 (8 sectors)
Alles anzeigen
Zu was gehört der?
Zu was gehört der?
Was ergibt ps -ef | grep LanguageInvoker | grep -v ps?
Leider nichts brauchbares.
Als Prozess wird nur grep LanguageInvoker angezeigt.
Dann läuft der Prozess auch nicht mehr oder er läuft im chroot von der HDStation/Kodi..
Ich vermute Letzteres.
Hatte extra zwei shells auf. In einem lief das Skript in dem anderen habe ich den Befehl sofort mehrmalsausgeführt, als die Platten wieder hochfuhren und mir das Skript im nachhinein den Prozess angezeigt hatte.
Ich habe jetzt myKodi 16.1 installiert und gestartet. Mal sehen, ob es sich hier genauso verhält.
Also, wenn mein NAS jetzt geweckt wird ist es die kodi.bin nachdem ich auf myKodi gewechselt hatte.
Also scheint derLanguage invoker wirklich zu dem Qnap Kodi zu gehören.
Immerhin dauert es jetzt länger bis myKodi die Platten wieder aufweckt.
Nur würde ich jetzt gerne rausfinden, warum das myKodi macht. Es ist über HDisplay gestartet, aber es erfolgt kein Zugriff. Läuft quasi im Hintergrund.
warum das myKodi macht.
Die Frage musst du an die Entwickler von Kodi stellen.
Hallo Zusammen,
ich habe mir vor 2 Wochen eine TS-453A (Firmware : 4.2.2 (20161102)) gekauft und betreibe Sie mit 2 WD Red WD80EFZX mit 8TB als Raid1/encrypted. Leider hindern 4-5 services den HDD Spindown. An der NAS habe ich bis jetzt nicht viel eingestellt. So habe ich Raid1 eingestellt, eine Linux Station mit Ubuntu 16.04 installiert (schon versucht testweise zu deinstallieren / deaktivieren, um zu prüfen, ob es an dieser liegt) und wegen dem Kontakt mit dem QNAP Service noch die App "QNAP Diagnostics Tool" installiert.
Insgesamt habe ich schon ca 10h damit verbracht im Internet bzw mit dem QNap Service nach einer Lösung für ständige Schreibzugriffe zu finden. So ist mir bekannt, dass die Firmware Version den Standby verhindern kann. Allerdings sollte der Schreibzugriff dann ca alle 30 Sek stattfinden und bei mir ist es deutlich häufiger (alle 3-4 Sekunden). In diesem Thread:
QTS 4.2.2 b20161021 => kein Festplattenruhezustand, HDDs gehen nicht mehr schlafen.
beschreibt der User Pamuko ein sehr ähnliches Problem zu meinem.
Ich habe es auch mit der Anleitung hier probiert: https://wiki.qnap.com/wiki/Hard_drives_spindown_issues
Dem Support hatte ich den angehängten log geschickt (leider zu lange um als Code einzubinden):
Ich hatte Ihnen außerdem die Infos aus dem QNAP Diagnostics geschickt, aber leider seit dem 22. November keine Antwort mehr erhalten.
top:
Mem: 2902784K used, 1045372K free, 0K shrd, 166692K buff, 1979972K cached
Load average: 0.21, 0.25, 0.24 (State: S=sleeping R=running, W=waiting)
PID USER STATUS RSS PPID %CPU %MEM COMMAND
28962 admin S N 11M 1 0.4 0.2 python
2579 admin S N 33M 1905 0.1 0.8 python2.7
28208 admin S 6064 10561 0.1 0.1 manaRequest.cgi
3592 admin S 5640 1 0.1 0.1 hal_daemon
27884 admin R 1944 16791 0.1 0.0 top
3836 admin S N 87M 3634 0.0 2.2 node
30049 admin S N 49M 29200 0.0 1.2 mysqld
1905 admin S N 40M 1790 0.0 1.0 python2.7
1788 admin S N 32M 1686 0.0 0.8 docker
2070 admin S N 31M 1686 0.0 0.8 docker
2543 admin S N 23M 1905 0.0 0.6 python2.7
3634 admin S N 20M 1787 0.0 0.5 python2.7
30446 admin S N 18M 1 0.0 0.4 mymediadbserver
2158 admin S N 18M 1 0.0 0.4 myupnpmediasvr
31486 admin S N 18M 1 0.0 0.4 dsd
1758 admin S N 17M 1756 0.0 0.4 mytranscodesvr
10980 admin S 17M 10979 0.0 0.4 php-fpm-proxy
2419 admin S N 17M 2417 0.0 0.4 php
1790 admin S N 17M 1686 0.0 0.4 python2.7
2539 admin S N 17M 2537 0.0 0.4 php
610 admin S N 16M 1 0.0 0.4 myidbserver
29730 httpdusr S N 16M 29706 0.0 0.4 php-fpm
10979 admin S 15M 1 0.0 0.3 php-fpm-proxy
29706 admin S N 15M 1 0.0 0.3 php-fpm
29727 httpdusr S N 15M 29706 0.0 0.3 php-fpm
1686 admin S N 14M 1 0.0 0.3 python2.7
10981 admin S 14M 10979 0.0 0.3 php-fpm-proxy
16428 admin S 13M 1 0.0 0.3 python
16429 admin S 13M 16428 0.0 0.3 python
16430 admin S 13M 16428 0.0 0.3 python
16431 admin S 13M 16428 0.0 0.3 python
16432 admin S 13M 16428 0.0 0.3 python
16433 admin S 13M 16428 0.0 0.3 python
16329 admin S 11M 1 0.0 0.2 smbd
2160 admin S N 11M 2070 0.0 0.2 docker-containe
16514 admin S 10M 1 0.0 0.2 python
7428 admin S 10M 1 0.0 0.2 python
2025 admin S N 10M 1788 0.0 0.2 docker-containe
16504 admin S 10M 1 0.0 0.2 python
7420 admin S 10M 1 0.0 0.2 python
Alles anzeigen
Man sieht im wesentlichen sind es Zugriffe durch md1_raid1, md9_raid1, jbd2/dm2-8, kjournal, kworker und verschiedene Zugriffe unter der Rubrik "dirtied inode". Ich würde mich sehr freuen, wenn mir jemand in der Sache weiterhelfen könnte, ansonsten habe 450 euro umsonst versenkt, da ich die NAS so nicht nutzen kann wg. der Lautstärke nachts.
Sollten noch irgendwelche wesentlichen Infos fehlen, versuche ich natürlich diese noch zusammen zu tragen.
Vielen Dank!
Im Anhang außerdem noch ein dump von ps
Eine Festplatte (es scheint nur eine der fünf HDDs zu sein) hat seit einer Weile alle 15 Sekunden einen Zugriff.
Kann man die Uhr nach stellen! Ich würde das nicht gerade als "spin-down-Problem" verstehen, weil das NAS doch nicht alle 15 Sekunden versuchen muss die Platten in den Standby zu fahren, oder? (Ich bin über diesen Thread hier gelandet, weil ein Admin dem ThreadErsteller gesagt hat, sein Problem wäre hier richtiger aufgehoben. Ich habe das gleiche Problem wie der TE des verlinkten Threads.)
Die Scan-Einstellung (unter Multimedia-Management) habe ich bereits ausgeschaltet! Kein Erfolg.
Das Protokoll mit blkdev monitor habe ich mal angehangen. Ich werde daraus nicht schlau.
kworker und kjournald scheinen relativ oft was zu machen. das hat vermutlich mit kodi zu tun? kann man das konfigurieren?
Für einen Tip wär ich dankbar!
@luckybamboo
Dein Log ist leider derartig verstümmelt, dass man ihm nicht wirklich etwas informatives entnehmen kann.
@TS851
Dein Problem ist exakt das hier beschriebene Seit QTS 4.2.2 b20161021 => kein Festplattenruhezustand, HDDs gehen nicht mehr schlafen.
@TS851Dein Problem ist exakt das hier beschriebene Seit QTS 4.2.2 b20161021 => kein Festplattenruhezustand, HDDs gehen nicht mehr schlafen.
Danke dr_mike! du hast's drauf!
seit ein paar Minuten ist Ruhe!
zumindest keine ständigen Zugriffe mehr. (was ja nicht heißt, dass sie auch schlafen gehen)
ich habe über den von Dir verlinkten Thread nicht downgegraded, sondern auf 4.3.2 beta upgegraded.
Mal sehen, ob das die richtige Entscheidung war!
Hallo,
ich bin noch auf der 4.2.2 und habe in der Log immer Meldungen vom dhcpd:
<7>[ 2177.538459] dhcpd_qlanbr0(21221): dirtied inode 27 (dhcpd_qlanbr0.leases) on md9<7>[ 2177.539170] dhcpd_qlanbr0(21221): dirtied inode 56 (dhcpd_qlanbr0.leases.1481035346) on md9
Ich nehme an, das kommt vom VirtualSwitch (br0 für container und VirtualStation). den Dienst kann ich aber scheinbar weder deaktivieren noch anderweitig beenden.
beim Start des blkdevMonitor-Scripts kommen u.a. Meldungen wie:
Stop klogd.sh daemon... Internet Systems Consortium DHCP Server 4.3.4
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Config file: /etc/dhcpd_qlanbr0.conf
Database file: /var/state/dhcp/dhcpd_qlanbr0.leases
PID file: /mnt/ext/opt/netmgr/api/core/dhcpdLink/qlanbr0.pid
Wrote 0 class decls to leases file.
Wrote 0 leases to leases file.
qlanbr0 missing an interface address
Failed to get interface index: No such device
Alles anzeigen
Das NAS selbst habe ich zum Test mit fester IP ausgestattet. Irgendeine Idee?
in dem VirtualSwitch läuft einer...einen separaten DHCP-Server habe ich nicht aktiviert und auch beim Deaktivieren der ganzen Dienste keinen gefunden
in der Systemsteuerung habe ich keinen unter Netzwerkdienst und Anwendungen gefunden. Unter Verwaltung-Systemservice ist kein DHCP-Server aufgelistet
/etc/dhcpd_qlanbr0.conf:
max-lease-time 259200;
default-lease-time 259200;
ddns-update-style interim;
allow booting;
allow bootp;
class "pxeclients" {
match if substring(option vendor-class-identifier,0,9)="PXEClient";
}
subnet 192.168.10.0 netmask 255.255.255.0{
interface qlanbr0;
range 192.168.10.11 192.168.10.254;
option routers 192.168.10.10;
}
Alles anzeigen
das ist genau das Subnet von "Netzwerk und virtueller Switch" - DHCP-Server...finde dort nur nirgends etwas um den zu deaktivieren...
lustigerweise verwende ich dieses Subnet gar nicht, denn Docker und LXC haben ein 10.x'er Subnet
dieser "Virtual Switch 3 (Privater Netzwerkmodus)" ist nichtmal aktiviert...aber ich konnte ihn löschen...mal schauen, ob der DHCP jetzt auch ruht...zumindest ist jetzt der Eintrag bei DHCP-Server auch raus...nur eigentlich sollte dieser ja auch so gestrickt sein, dass er nur ab und zu auf platte schreibt (ich hatte das lt. Log jede Minute)...ganz besonders, wenn keine "leases" vorhanden sind
werde das morgen mal testen, obs ruhig bleibt
lustigerweise verwende ich dieses Subnet gar nicht,
Dann kannst du den Eintrag ja löschen.
hab ich und zusammen mit dem patch der network.sh gehen die hdds schonmal in standby...ab und zu weckt vg1.log, ctstation.log und CACHEDEV1_DATA.log / CACHEDEV2_DATA.log noch auf aber ist schonmal ein Fortschritt
das sind die Pfade von den Log-Files:
/mnt/HDA_ROOT/.config/storage_usage_history/CACHEDEV1_DATA.log
/mnt/HDA_ROOT/.config/storage_usage_history/vg1.log
kann man diese usage-History deaktivieren?
/share/CACHEDEV1_DATA/.qpkg/container-station/var/log/container-station/ctstation.log
in der container-Station läuft aktuell auch kein Container...somit sollte imho auch keine Log geschrieben werden...
[2016-12-07 17:45:16,837][Web ][INFO ] Processed Qnet DHCP renew (network.py:566)
[2016-12-07 18:15:16,820][Web ][INFO ] Processing OnlineData update (__init__.py:458)
[2016-12-07 18:15:16,820][Web ][INFO ] Try to update container apps (__init__.py:207)
[2016-12-07 18:15:16,825][Web ][INFO ] run: ['/usr/local/container-station/git/bin/git', 'ls-remote', 'git://github.com/qnap-dev/container-apps/', 'master'] (util.py:95)
[2016-12-07 18:15:16,839][Web ][INFO ] Processing Qnet DHCP renew (network.py:557)
[2016-12-07 18:15:16,839][Web ][INFO ] Processed Qnet DHCP renew (network.py:566)
[2016-12-07 18:15:17,134][Web ][INFO ] Already have latest container apps list (__init__.py:216)
[2016-12-07 18:15:17,134][Web ][INFO ] Processed OnlineData update (__init__.py:469)
[2016-12-07 18:45:16,869][Web ][INFO ] Processing Qnet DHCP renew (network.py:557)
[2016-12-07 18:45:16,869][Web ][INFO ] Processed Qnet DHCP renew (network.py:566)
kann man diese Zugriffe auch noch verhindern (ohne die CS zu deaktivieren)?
Edit:
warum macht man solche Sachen nicht in eine RAM-DISK und schreibt die Daten in größeren intervallen bzw. wenn HDD Standby beendet wurde (durch Zugriff von woanders [auf Shares]) auf Platte.
hallo dr mike,
ich habe nochmal einen log gemacht und ps am ende angehängt und dieses mal den log mit dem Terminl abgespeichert statt rauszukopieren. Ich hoffe damit ist es besser lesbar für dich. Ich hatte das zuerst rauskopiert, um es hier als Code einzufügen. Es waren aber zu viele Zeichen.
Ich habe auch einen Screenshot von System Status gemacht: Extern verlinktes Bild entfernt! Der Grund!
Ich hoffe das hilft auch besseres Gesamtbild zu verschaffen was aktuell läuft.
Wenn ich den Log selber betrachte, fällt mir auf, dass es im wesentlichen 4-5 Arten von Schreibzugriffen sind:
<7>[15242.881896] md9_raid1(2096): WRITE block 1060216 on sdb1 (1 sectors)<7>[15242.895032] md9_raid1(2096): WRITE block 1060232 on sdb1 (1 sectors)<7>[15258.473422] md9_raid1(2096): WRITE block 1060216 on sdb1 (1 sectors)<7>[15258.493872] md9_raid1(2096): WRITE block 1060232 on sdb1 (1 sectors)<7>[15258.703410] md9_raid1(2096): WRITE block 1060216 on sdb1 (1 sectors)<7>[15258.714585] md9_raid1(2096): WRITE block 1060232 on sdb1 (1 sectors)<7>[15272.696946] md9_raid1(2096): WRITE block 1060216 on sdb1 (1 sectors)<7>[15272.716126] md9_raid1(2096): WRITE block 1060232 on sdb1 (1 sectors)
<7>[15288.487533] kjournald(2107): WRITE block 532376 on md9 (8 sectors)<7>[15288.487543] kjournald(2107): WRITE block 532384 on md9 (8 sectors)<7>[15288.487554] kjournald(2107): WRITE block 532392 on md9 (8 sectors)<7>[15288.487565] kjournald(2107): WRITE block 532400 on md9 (8 sectors)<7>[15288.487576] kjournald(2107): WRITE block 532408 on md9 (8 sectors)<7>[15288.487587] kjournald(2107): WRITE block 532416 on md9 (8 sectors)<7>[15288.487597] kjournald(2107): WRITE block 532424 on md9 (8 sectors)<7>[15288.487939] kjournald(2107): WRITE block 532432 on md9 (8 sectors)
<7>[15272.718988] kworker/u8:2(3227): WRITE block 262600 on md9 (8 sectors)<7>[15272.719003] kworker/u8:2(3227): WRITE block 393216 on md9 (8 sectors)<7>[15272.719019] kworker/u8:2(3227): WRITE block 0 on md9 (8 sectors)<7>[15272.719031] kworker/u8:2(3227): WRITE block 8 on md9 (8 sectors)<7>[15272.719042] kworker/u8:2(3227): WRITE block 262416 on md9 (8 sectors)<7>[15272.719053] kworker/u8:2(3227): WRITE block 262424 on md9 (8 sectors)<7>[15272.719064] kworker/u8:2(3227): WRITE block 262432 on md9 (8 sectors)
<7>[15282.699816] setcfg(12337): dirtied inode 6988 (uLinux.conf.bak) on md9
<7>[15282.704392] setcfg(12338): dirtied inode 6843 (uLinux.conf.bak) on md9
<7>[15282.712256] setcfg(12340): dirtied inode 6988 (uLinux.conf.bak) on md9
<7>[15282.720080] setcfg(12342): dirtied inode 6843 (uLinux.conf.bak) on md9
<7>[15282.727845] setcfg(12344): dirtied inode 6988 (uLinux.conf.bak) on md9
Ich hoffe ihr könnt mir ein paar Tips geben, wie ich das in den Griff bekomme.