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

Ich muss mich hier leider anschließen...

Ich fühle mich nun zunehmend genervt von ständigen Schreibgeräuschen des RAID5 hier ohne erkennbare Gründe...

Alles an Diensten oder Prozessen deaktiviert, was möglich, LAN-Kabel abgezogen - egal, die Möhre knöckelt dauerhaft vor sich hin....

Ich bin ja nicht anspruchsvoll und erwarte HDD standby - aber es kann doch nicht sein, dass 24/7 Schreibaktivitäten stattfinden - für was? Neben der aktustischen Belästigung sollte das auch die HDD-Lebensdauer sicher beeinflussen ....

Augenscheinlich ein Dauerthema bei QNAP - wie ist das eigentlich bei den Synologen?

Pic01.png

Solange die Web-Oberfläche geöffnet ist wird immer geschrieben und gelesen. Dein Bild ist also nichtssagend.

Ich war mir jetzt auch nicht sicher ob es nur die Frage war wie es bei Syno läuft oder ob wir das Problem ernsthaft angehen wollen (dazu würden die beiden irgendwo erwähnten Tests eventuell Aufschluss geben können)...

Oh... Post 219 war vorbildlich und wurde nicht bearbeitet... Das zeigt wie kompliziert das Thema ist

Zitat von dr_mike

Solange die Web-Oberfläche geöffnet ist wird immer geschrieben

Ist mir prinzipiell bekannt, aber die vernehmbare Geräuschkulisse ist die gleiche, 24/7

Zitat von tiermutter

Ich war mir jetzt auch nicht sicher ob es nur die Frage war wie es bei Syno läuft oder ob wir das Problem ernsthaft angehen wollen ...

Vielleicht war es tatsächlich eher eine Frust-getriebene "Frage" meinerseits, da ich bei all den hier bereits existierenden Threads - auch unter Nutzung der irgendwo erwähnten Tests - nicht den Eindruck gewonnen habe, dass dies (bei QNAP?) nachhaltig aufklärbar oder gar abstellbar gewesen wäre...

von HDD-Standby will ich nicht mal träumen 😴

Auch wenn mich einige steinigen: ich verweise noch einmal auf Beitrag #101 mit weiterem Verweis: HDD-Standby ist prinzipiell möglich und funktioniert bei mir, seitdem ich die vom Betriebssystem angelegten RAID 1 Verbünde md9 und md13 aufgelöst habe. Das ist zwar keine hinreichende Bedingung (- andere Störzugriffe können noch hinzukommen -), aber eine notwendige Bedingung. Ohne ein Abschalten dieser RAID-Zugriffe auf alle HDDs durch das Betriebssystem kann HDD- Standby nicht klappen.

Danke für den Hinweis, das schau ich mir mal genauer an, geht halt leicht unter im Gesamt-Thema 👍🏻

Hallo, ist es möglich, dass ich meinen TS-464 mit 4 HDDs und 2 SSDs bestücke und den QNAP so konfiguriere, dass die SSDs genutzt werden, die HDDs währenddessen aber im Schlafmodus sind?

Der Festplatten-Standyb ist ein kniffeliges Thema bei QNAP.

In einigen Szenarien funktionirt er, bei anderen jedoch nicht.

Generell gilt, je mehr Dienste du auf dem System laufen läßt, desto unwahrscheinlicher ist der Standby.

Hallo,

wenn das Systemvolumen mit den Apps auf den SSD liegt, kannst Du die Festplattenzugriffe schon reduzieren.

Blog-Artikel

(Betriebs)- System vs. Systemvolume - Hinweise zum Verständnis

[PROLOG]
Auf SSD läuft alles etwas flotter als auf HDD, das ist weitbekannt und so kommt auch bei QNAP NAS immer wieder das Thema „System auf SSD installieren / verschieben“ auf.
Auch bei diesem Thema wird dann immer wieder dasselbe gepredigt und versucht den Unterschied zwischen System und Systemvolume zu erklären. Auch diesmal will ich Abhilfe schaffen und den Unterschied hier erläutern, damit zukünftig einfach hierher verwiesen werden kann.

[DAS SYSTEM (BETRIEBSSYSTEM) ]
Das Betriebssystem (der…

tiermutter

30. November 2023

Die Methode ist aber kein Garant und wird eher nicht funktionieren. Also reduzieren schon, aber selbst das hilft in den meisten Fällen nicht.

Die einzige Lösung die wirklich funktioniert wäre die inoffizielle Möglichkeit die HDD aus dem System-RAID zu entfernen. Ist aber schon ein starker Eingriff der zB immer dann rückgängig gemacht werden muss, wenn eine der Disks getauscht wird oder wenn die Hilfe vom Support benötigt wird (der uU sogar im Dumplog sieht was da angestellt wurde und demnach die Hilfe verweigern könnte).

Zitat von Julia2023

Hallo, ist es möglich, dass ich meinen TS-464 mit 4 HDDs und 2 SSDs bestücke und den QNAP so konfiguriere, dass die SSDs genutzt werden, die HDDs währenddessen aber im Schlafmodus sind?

Prinzipiell ist das der einzig erfolgversprechende Ansatz. Wie von Tiermutter schon erwähnt, muss das System-RAID so konfiguriert werden, dass dieses ausschließlich auf die SSDs zugreift (siehe Beitrag #101). Ich stimme tiermutter zu, dass das ein nicht ganz unproblematische Eingriff in das Betriebssystem ist, aber ohne diesen Eingriff ist ein Ruhemodus der HDDs prinzipiell nicht möglich.

Hi, hab ein Problem mit meinem TS-831X und dauernder Aktivität der RAID5 Platten.

Hab 5x10TB Platten im Raid5 laufen die laut Systemsteuerung auch alle einwandfrei laufen.
Ein Resync, Rebuild oder ähnliches ist nicht am laufen. Die RAID5 Platten rattern und die LEDs blinken wild, als würde eine Indexierung laufen, die hab ich aber auf dem NAS soweit deaktiviert. Auch Multimediaserver und oder KI Tools hab ich nicht laufen. Also von der Seite dürfte auch nichts indexiert werden.

Screenshot 2024-07-10 100503.jpg

Folgende Dienste sind am laufen zur Zeit:
Screenshot 2024-07-10 100041.jpg

Um mal nen Überblick zu bekommen hab ich den blkdevmonitor mal angeworfen.
Der zeigt eigentlich nur Samba Zugriffe.
Komischerweise bin ich momentan nur mit nem Windows Rechner online und greife noch nicht mal auf das NAS zu.

Auch andere mobile Geräte sollten immo keine NAS Zugriffe veranstalten.
Die CPU Auslastung ist ständig über 90%.

Screenshot 2024-07-10 102000.jpg

Hat jemand ne Idee? Selbst das Trennen der Netzwerkverbindung für mehr als ne Stunde bringt die Platten nicht zur Ruhe.
Firmware ist auf neustem Stand (QTS 5.1.7.2770).

Hier mal das Ergebnis des Monitoring per ssh:

[~] # /root/blkdevmonitor.sh
===== Welcome to blkdevmonitor on Wed Jul 10 10:00:06 CEST 2024 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1
Start...
============= 0/10 test, Wed Jul 10 10:00:15 CEST 2024 ===============
<7>[56873.198411] smbd(19472): READ block 30505647456 on dm-0 (8 sectors)
<7>[56873.198920] smbd(19472): READ block 30505647464 on dm-0 (8 sectors)
<7>[56873.199293] smbd(19472): READ block 30505647472 on dm-0 (8 sectors)
<7>[56873.199642] smbd(19472): READ block 30505647480 on dm-0 (8 sectors)
<7>[56873.199990] smbd(19472): READ block 30505689376 on dm-0 (8 sectors)
<7>[<7>[56873.21185<<<7>[568<7>[56<7>[5<7>[56<7>[56<7>[56873.215638] smbd(19472): READ block 30505688768 on dm-0 (8 sectors)
<7>[56873.215964] smbd(19472): READ block 30505688776 on dm-0 (8 sectors)
<7>[56873.220711] smbd(19472): READ block 30505688808 on dm-0 (8 sectors)
<7>[56873.221062] smbd(19472): READ block 30505688824 on dm-0 (8 sectors)

============= 1/10 test, Wed Jul 10 10:00:18 CEST 2024 ===============
<7>[56876.905570] smbd(17904): READ block 18507814112 on dm-0 (8 sectors)
<7>[56876.905666] smbd(19472): READ block 30508609880 on dm-0 (8 sectors)
<7>[56876.906204] smbd(19472): READ block 30508710896 on dm-0 (8 sectors)

============= 2/10 test, Wed Jul 10 10:00:21 CEST 2024 ===============
<<7>[56879.626835] smbd(17904): READ block 21537767688 on dm-0 (8 sectors)
<7>[56879.626863] smbd(17904): READ block 21537767680 on dm-0 (8 sectors)

============= 3/10 test, Wed Jul 10 10:00:23 CEST 2024 ===============
<7>[56891.460869] smbd(19472): RE<7>[56891.503780] smbd(19472): READ block 30495126968 on dm-0 (8 sectors)

============= 4/10 test, Wed Jul 10 10:00:35 CEST 2024 ===============
<7<<7>[56894.013305] smbd(17904): READ block 17936768632 on dm-0 (8 sectors)
<7>[56894.041312] smbd(17904): READ block 20380968360 on dm-0 (8 sectors)
<<7>[56894.075964] smbd(17904): READ block 19084132616 on dm-0 (8 sectors)
<<7>[56894.083805] smbd(17904): READ block 20380968560 on dm-0 (8 sectors)
<<<7>[56894.125662] smbd(17904): READ block 18507710424 on dm-0 (8 sectors)
<7>[56894.129968] smbd(17904): READ block 18507710408 on dm-0 (8 sectors)
<7>[56894.133102] smbd(17904): READ block 18507710416 on dm-0 (8 sectors)

============= 5/10 test, Wed Jul 10 10:00:39 CEST 2024 ===============
<7>[56899.744820] smbd(17904): READ block 17879382336 on dm-0 (64 sectors)
<7>[56899.746759] smbd(19472): READ block 32002605928 on dm-0 <7><<<<7>[56899.809646] sm<7>[5

============= 6/10 test, Wed Jul 10 10:00:43 CEST 2024 ===============
<7>[56902.064497] smbd(17904): READ block 20891444696 on dm-0 (8 sectors)

============= 7/10 test, Wed Jul 10 10:00:46 CEST 2024 ===============
<7>[56904.48460<7>[56904.565451] smbd(19472): READ block 30499513648 on dm-0 (8 sectors)
<7>[56904.573669] smbd(19472): READ block 30499569656 on dm-0 (8 sectors)
<<7>[56904.630183] smbd(17904): READ block 18371124312 on dm-0 (8 sectors)
<7>[56904.638978] smbd(19472): READ block 30503143280 on dm-0 (8 sectors)
<7>[56904.643199] smbd(19472): READ block 30503303288 on dm-0 (8 sectors)

============= 8/10 test, Wed Jul 10 10:00:49 CEST 2024 ===============
<<<7<<7<7><7><7>[5<7>[56<7>[5690<<7>[56<7>[56<7>[56<7>[56<7>[56<7<<7>[56907.321440] smbd(19472): READ block 30463411648 on dm-0 (8 sectors)
<7>[56907.345407] sm<<<<<<7>[56907.379045] smbd(19472): READ block 30404616304 on dm-0 (8 sectors)
<7>[56907.379627] smbd(19472): READ block 30404616328 on dm-0 (8 sectors)
<<<<<7>[56907.392566] smbd(17904): READ block 18408876632 on dm-0 (8 sectors)

============= 9/10 test, Wed Jul 10 10:00:52 CEST 2024 ===============
<7>[5<7>[56912.166130] smbd(17904): READ block 20311309936 on dm-0 (8 sectors)

Turn off block_dump
Start klogd.sh daemon

Schau mal im Ressourcen-Monitor, welche Prozesse denn laufen.

Ich würde anfangen die Ursache für die CPU Last zu suchen... schau mal welcher Prozess hier so viel verwendet.

Ja Danke, es ist tatsächlich Samba, wie laut Monitoring zu erwarten war, obwohl ich zur Zeit eigentlich keine Zugriffe mache. Komisch.

Werd das NAS nochmal Neustarten...

Ja Neustart ist immer Maßnahme Nr. 1

Danach nochmal Firmware drüberbügeln wenn das nichts gebracht hat.

Hab ich's überlesen, oder hast Du noch nicht geschrieben, welche FP's Du eingebaut hast?

Ansonsten: Ist das NAS aus dem Internet erreichbar?

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

Das NAS ist ausser über VPN nicht von aussen erreichbar und der VPN Dienst läuft auch nicht auf dem NAS sondern auf nem Wireguard Docker auf meinem UNRAID Server. VPN ist auch nicht aktiv. Und wie gesagt, hatte ja auch schon die Netzwerkkabel ab. WLAN Modul ist natürlich keins verbaut.
Neustart hat nicht wirklich was gebracht, war kurz Ruhe und jetzt rattern die Platten wieder. Der Zugriff auf die Ordner ist auch dementsprechend langsam.
So wie die Platten arbeiten kenn ich das eigentlich nur von der Indexierung oder nem Raid-Rebuild.
Die Firmware nochmal drüber zu bügeln macht tatsächlich Sinn? Eventuell mach ich es auch mal auf und geh mal an den Staub. Läuft jetzt schon ne ganze Zeit seit dem letzten reinigen...

Hmm, ansonsten irgendjemand aus Deiner Familie, der sich ein Verschlüsselungstrojaner eingefangen haben könnte und der gerade Dein NAS verschlüsselt?