[5. Sammelthema] Probleme mit Festplatten-Standby (1.Beitrag beachten)

Da wäre aber beim Trennen des Netzwerkes der Zugriff weg (und das HDD blinken), da das NAS ja nicht selbständig verschlüsselt.

Zitat von derpuma

Hi, also im RAID sind 5 WD Red mit je 10TB, RAID5. Also alles Platten die für NAS geeignet sind.

Zitat von derpuma

So wie die Platten arbeiten kenn ich das eigentlich nur von der Indexierung oder nem Raid-Rebuild

Moin, hab halt das gleiche Problem gehabt mit den WD Red (allerdings 4TB, die waren SMR und trotzdem empfohlen für QNAP NAS). Aber Deine 10TB sind schon seit jeher CMR. Die WD hab ich rausgeschmissen, und hab nun 4TB Seagates drin. Da ist Ruhe...

Zitat von derpuma

Die Firmware nochmal drüber zu bügeln macht tatsächlich Sinn

Joo, wird hier oft propagiert

Zitat von derpuma

Eventuell mach ich es auch mal auf und geh mal an den Staub. Läuft jetzt schon ne ganze Zeit seit dem letzten reinigen...

Das hilft immer (für die Lüfter). Mach ich auch einmal im Jahr

Die FP Nr. 3 ist 50 Grad heiß. Das sind 5 Grad mehr, als die nächsthöchste Temperatur. Ob das damit zu tun hat?

Seit diesem Monat habe ich keinen Hobbykeller mehr. (Eigenbedarfskündigung - don't ask...)

Nun steht mein TS-233 in der Wohnung und ich höre, wenn die Festplatten aktiv sind.

Das ist zu meiner Überraschung eigentlich immer.

Selbst wenn im ganzen LAN kein Client aktiv ist, rappelt das Teil alle fünf Sekunden mal kurz, mal länger mit dem typischen Kopfpositionierungsgeräusch.

Auf dem Gerät laufen außer den Standard-Apps, die QNAP einem aufs Auge drückt:

• HBS3 mit einigen "Schedule: Auto-backup" Jobs, zwei "Daily" Jobs und einem "Real-time synch" Job, den ich versuchsweise mal deaktiviert habe, was aber an dem ständigen Gerappel nichts geändert hat
• Container Station mit zwei Containern, die per Crontab einmal am Tag gestartet werden, wenige Minuten laufende Backup-Jobs ausführen und sich wieder beenden
• MinimServer; auch den habe ich mal versuchsweise gestoppt, das Gerappel alle 5 Sekunden ging trotzdem weiter

Da ich die Frage schon kommen sehe: Nein, das Gerät ist nicht aus dem Internet erreichbar.

Hat jemand eine Idee, um herauszufinden, was die ständigen Festplattenzugriffe verursacht?

Na auf jeden Fall erstmal die obligatorischen Tests starten:

Blog-Artikel

Mysterium Datenträger-Standby - Über Sinn, Unsinn und wie man ihm auf den Grund gehen kann

[PROLOG]
Festplatten abschalten wenn keine Zugriffe erfolgen ist eins der größten Mysterien in der QNAP-Welt, nicht umsonst sind die Threads zum Festplattenstandby (Festplatten) in der mittlerweile 4. Generation etliche Seiten lang. Doch was bewegt das NAS dazu, die Festplatten aktiv zu halten, was kann man dagegen tun und warum sollen die Festplatten überhaupt in den Standby gehen?

In den angesprochenen Threads (siehe erster Post) wird schon einiges darüber ausgesagt, der Rest ist über die…

tiermutter

25. Mai 2022

Ich möchte gar nicht, dass die Festplatten sich abschalten. Die sollen sich ruhig weiterdrehen. Das ist sowohl für die Lebensdauer der Platten besser als auch für die ohnehin nicht gerade berückende Zugriffszeit nach längerer (oder kürzerer) Nichtnutzung. Deshalb ist bei mir auch die Option "Enables disk standby mode" (sic!) im Control Panel ganz bewusst nicht aktiv. Das funktioniert auch sehr gut - die Platten gehen, wie gewünscht, nicht in den Standby. Das gleichmäßige Summen stört mich nicht.

(Deshalb bin ich auch nicht überzeugt, ob es wirklich eine so gute Idee war, meine Frage gegen meinen Willen in diesen Thread hier zu verschieben - aber sei's drum, ich möchte mich deshalb nicht zanken.)

Aber die Ironwolfs, die ich verbaut habe, produzieren neben dem Summen der Rotation eben auch ein erheblich lauteres, unregelmäßiges Rappelgeräusch bei der Bewegung der Schreib-/Leseköpfe. Auch erträglich, aber es fällt halt auf, dass da ständig Aktivität ist.

Deinen Blog-Artikel habe ich mir durchgelesen, finde da aber auf Anhieb nichts, was zu dem von mir beobachteten Phänomen (Festplattenzugriffe alle fünf Sekunden) passen würde.

In /var/log sind einige Dateien, in denen quasi permanent neue Einträge auftauchen, vor allem hal_lib.log, gpuhal.log (mit dem sehr "interessanten" Access Mode r-x--xr-x - aber das nur am Rande) und storage_lib.log, aber zum einen korreliert das Erscheinen dieser Einträge, wenn ich es per tail -f live verfolge, nicht mit dem Plattengerappel, und zum anderen liegt /var/log soweit ich sehe im RAM (type tmpfs), sollte also beim Zugriff nicht rappeln.

Ich bin der Meinung, dass durchlaufende Platten bei einem NAS sinnvoll sind (ausser, man nutzt es nur als gelegentliche Datenhalde).

Meine beiden WD30EFRX (RAID 1) laufen so seit 2572 Tagen (26 Neustarts) durch und machen keinerlei Probleme.

Tschau

Uwe

Ja, da sind wir uns ja einig. Die Spindelmotoren sollen bitte gerne anbleiben.

Trotzdem wüsste ich halt gerne, was das für Zugriffe alle fünf Sekunden sind.

Noch jemand irgendeine Idee, wie man dem auf die Schliche kommen könnte?

echo 1 > /proc/sys/vm/block_dump

und danach

dmesg | tail

könnte verraten, welcher Prozess auf die Platten schreibt, falls QNAP das unterstützt.

Tschau

Uwe

... und wenn nicht, dann ist ja in #245 verlinkt, wie man das bei QNAP auf zwei unterschiedliche Methoden ermitteln kann...

Siehe #246

blkdev:

Zitat von tiermutter

Mittlerweile ist der Test ganz einfach über die Helpdesk-App unter „HDD Standby Test“ abrufbar.

Disk Standby Debug:

Zitat von tiermutter

Code

cd /tmp
wget --no-check-certificate https://download.qnap.com/Storage/tsd/utility/Disk_Standby_Debug
chmod 755 Disk_Standby_Debug
for (( i=1; i<=30; i=i+1 )); do ./Disk_Standby_Debug --file 300 ; cat /var/ledvalue; echo -----${i}------;sleep 300; done 2>&1 | tee /share/Public/Standby_test.log

Das könnte ja verraten was da alle 5s schreibt...

Glaube mir tgsbn , Du bist hier schon richtig mit Deinem Problem. Dieses Thema könnte genausogut heißen "Warum wird ständig auf die Platten zugegriffen?".

Es geht hier nämlich nicht darum, dass die Firmware der Festplatten, welche für den Standby der FP alleinig verantwortlich ist wenn keine Zugriffe erfolgen, fehlerhaft ist.

Hier geht es ausschließlich um permanente Zugriffe auf die FP, die Verhindern, dass die Platten-Firmware ihre Aufgabe wahrnehmen kann. Schaltest Du diese Aufgabe ab:

Zitat von tgsbn

Deshalb ist bei mir auch die Option "Enables disk standby mode" (sic!) im Control Panel ganz bewusst nicht aktiv.

bleiben die Zugriffe auf die Platten trotzdem bestehen.

Den über die Helpdesk-App unter „HDD Standby Test“ abrufbaren Test habe ich jetzt mehrfach laufen lassen.

Er liefert beim Download zuverlässig reproduzierbar jedesmal eine Datei "blk_tmp" mit 0 Bytes Größe, was mir nicht wirklich weiterhilft.

Als nächstes probiere ich dann mal aus, ob bei "Disk Standby Debug" mehr herauskommt.

[/tmp] # wget https://download.qnap.com/Storage/tsd/utility/Disk_Standby_Debug
--2024-08-08 21:23:32--  https://download.qnap.com/Storage/tsd/utility/Disk_Standby_Debug
Resolving download.qnap.com... 2600:9000:2490:d000:1c:350a:340:93a1, 2600:9000:2490:b200:1c:350a:340:93a1, 2600:9000:2490:f400:1c:350a:340:93a1, ...
Connecting to download.qnap.com|2600:9000:2490:d000:1c:350a:340:93a1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 23557 (23K) [binary/octet-stream]
Saving to: ‘Disk_Standby_Debug’

Disk_Standby_Debug 100%[===================>]  23.00K  --.-KB/s    in 0s      

2024-08-08 21:23:33 (46.7 MB/s) - ‘Disk_Standby_Debug’ saved [23557/23557]


[/tmp] # chmod +x Disk_Standby_Debug 
[/tmp] # ./Disk_Standby_Debug 
-sh: ./Disk_Standby_Debug: cannot execute binary file
[/tmp] # 

Ich vermute mal falsche CPU-Architektur.

tilman@Neon:~$ file Disk_Standby_Debug 
Disk_Standby_Debug: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=1fb5393fe5ba13d849ce1ed8d9d9ea1f2250a16d, not stripped

Yup. Ist ein Intel-Executable. Na, ich schau mal ob es das auch für ARM gibt.

Ja, gibt es.

wget https://download.qnap.com/Storage/tsd/utility/Disk_Standby_Debug_arm64/Disk_Standby_Debug

Läuft jetzt allerdings schon seit einer Stunde und ist immer noch nicht terminiert.

Ich habe mal mit lsof nachgeschaut, was es eigentlich tut.

Offenbar durchläuft es auf der Suche nach möglicherweise angefassten Dateien den kompletten Dateibaum inklusive aller Snapshots.

Im Moment ist es in /mnt/snapshot/1/10005/ unterwegs, d.h. im fünften von fünfzehn Snapshots meines Hauptvolumes.

Das kann also noch dauern.

Ich gehe wohl besser ins Bett und schaue morgen, wie weit es gekommen ist.

Eigentlich sollte der Test (wie ich ihn beschrieben habe) nach spätestens 2,5h (30*300s) abgeschlossen sein...

Du gehst davon aus, dass die Laufzeit von Disk_Standby_Debug selbst vernachlässigbar wäre.

Das trifft zumindest auf meiner TS-233 nicht zu.

Eine Ausführung von Disk_Standby_Debug --file 300 dauert hier ca. 1h 35min.

Damit lautet die Rechnung: 30*(5700+300)s = 50h.

Im Moment ist er in Durchlauf 5/30.

Ich melde mich übermorgen wieder.

Disk_Standby_Debug --file 300 schreibt doch alle 5min die Ausgabe in die Logdatei und sleep 300 wartet dann 5min.

Demnach dürfte das doch keine 1h35 dauern, sondern eben 5min

Aber wenn es so ist, dann ist das so... dann mal frohes warten, und schön das NAS in Ruhe lassen, damit das Ergebnis nicht verfälscht wird

Nein, Disk_Standby_Debug --file 300 schreibt nicht alle 5min die Ausgabe in die Logdatei.

Disk_Standby_Debug --file 300 nudelt einmal das komplette Filesystem nach Dateien durch, die in den letzten 300 Sekunden angefasst wurden.

Das dauert auf meinem Maschinchen 1h35. (Auf edleren Teilen mag das schneller gehen.)

Dann schreibt es das Ergebnis auf seinen standard output, das geht relativ schnell.

Danach beendet sich Disk_Standby_Debug.

Das nachfolgende cat und echo kann man laufzeitmäßig tatsächlich vernachlässigen.

Erst dann beginnt der sleep 300.

Das läuft alles ganz sequenziell und deshalb summieren sich die Zeiten.

tgsbn

Nur mal zur Nachfrage, ist Dein NAS online, ich meine mit einer Cloud verbunden oder soll aus dem Internet erreichbar sein? Ich frage deshalb, weil ich mit meiner TS121, welche ich nur innerhalb meines Homenetzes als Datengrab und Verteiler von Inhalten nutze, seit einigen Anpassungen der chrond.sh und crontab Ruhe habe. Genauer gesagt wird in der crontab als einzige Aufgabe 00 9 * * * /sbin/hwclock -s geführt und die chrond.sh habe ich auf das Notwendigste eingekürzt, Bezüge auf die Cloud und Anfragen über das Internet an QNAP rausgeschmissen. Da jetzt auch keine Suche mehr nach Zertifikaten stattfindet, ist Ruhe. Einmal noch bei ausgeschaltetem Netzwerk dreht der Lüfter hoch, wenn im Hintergrund noch vermutlich Verwaltungsaufgaben erfüllt werden, wobei die HDD im Ruhezustand bleibt. Mein NAS selber bleibt 7/24 eingeschaltet. So der Linux-Profi bin ich zwar nicht, aber durch Tests habe ich die für mein System relevanten Einstellungen gefunden.

Ich befürchte nur, dass man die beiden Modelle (bzw die OS) nicht mehr wirklich vergleichen kann... da liegen Welten dazwischen...