[3. Sammelthema] Probleme mit Festplatten-Standby

    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.

    Einmal editiert, zuletzt von Krisch.Nas ()

    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.



    Zu was gehört der?

    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.

    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:


    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!

    Zitat von dr_mike

    @TS851Dein Problem ist exakt das hier beschriebene :arrow: Seit QTS 4.2.2 b20161021 => kein Festplattenruhezustand, HDDs gehen nicht mehr schlafen.

    Danke dr_mike! du hast's drauf! :thumbup:
    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:

    Code
    <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:


    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:


    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

    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...


    Code
    [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.

    4 Mal editiert, zuletzt von frank-w ()

    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:


    Code
    <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)
    Code
    <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)
    Code
    <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)
    Code
    <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. :(