QSYNC Prozess qsyncsrv_metad / Festplatte läuft ständig

Hi Norbert,

ich habe das gleiche Problem, somit ist es zumindest schon mal kein Einzelfall mehr

Ich habe festgestellt, dass der qsyncsrc_metad nachdem er ein Volumen (in meinem Fall das Grösste) "durchgegangen" ist, mit einem SIGSEGV auf die Nase fällt. 30 Sekunden später versucht er das dann wieder und so weiter... Warum das passiert habe ich noch nicht verstanden, aber ich hoffe mal, dass es durch ein Firmware Update behoben wird.

lb,

Tob

bei mir das gleiche, bin zurück auf 4.4.1 da ist wieder alles gut. Hab die TS-431P2. Mit dem letzten Build 4.4.2.1273 build 20200413 noch das gleiche begonnen hats mit: 4.4.2.1270 build 20200410.

Meine Festplatte rödelt auch "ständig" (immer kurze Unterbrechung, aber dann gehts wieder los) seit dem letzten Update.

Gibt'e eigentlich mal ne Firmware der man vertrauen kann?

Auch mit der: 4.4.2.1302 build 20200512 2020-05-12 das gleiche, aber warum auch Fehler beheben wenn man die Zeit nutzen kann um nicht abschaltbare Werbebanner einzubauen. Und wieder zurück auf die 4.4.1...

Zitat von Timmiotool

aber warum auch Fehler beheben wenn man die Zeit nutzen kann um nicht abschaltbare Werbebanner einzubauen.

Und ich dachte, man könne die Zeit auch nutzen, neue Fehler einzubauen. So eine Art implizite Jobgarantie für die Serviceabteilung und die Entwicklungsabteilung von der Entwicklungsabteilung. Wenn da nicht auch noch Kunden wären, die bei solchen internen Machtkämpfen nicht mitmachen und so etwas wie Kundenzufriedenheit wünschen.

In den Changelogs steht dazu nichts aber:

mit dem neunen Build 4.4.2.1310 ist der Fehler nun behoben !

Werbebanner gibts auch nicht mehr, na sowas

Jetzt hab ich mich gestern gefreut, die Werbebanner und das Werbe Pop-Up trickreich entfernt zu haben und heute gibts schon ein FW-Update, welches diesen Job auch erledigt!

Man sollte sich halt nicht nervös machen lassen!

Hoffentlich gibts jetzt keine neuen Verschlimmbesserungen.

Trotzdem Danke an das Qnap-Team für die gar nicht so langsame Reaktion auf das aufgeregte Summen im Kundenbienenstock!

Hallo,

@qurmba und Timmiotool, ist bei euch nun der permanete zugriff auf die HDDs mit der 1310er Version weg?

Bei mir sind die HDD´s nachwievor dauernd am rödeln.

bei mir ist jetzt alles wieder ok, qsyncsrv_metad meldet sich nicht mehr in Endlosschleife - Hdds gehen wieder in den Standby. Ohne Dein Setup zu kennen, ständige HDD Zugriffe können auch andere Ursachen haben (Beispiel: Container Station) -> Zum Test am besten mal alle Apps deaktivieren bis auf QSync und schauen was passiert. Der Ressourcenmonmitor hilft meistens auch schon weiter um zu sehen ob da ein Prozess ständig läuft.

Ups, hab ja mein Profil noch nicht angepasst.
Also es handelt sich um die neue TS253BE, die ich seit einer Woche habe. Diese hat seit beginn an das Problem.
Es wurde zwar schon etwas leihter, so alle 5 Minuten hört man kurz wie die HDD´s verstummen und dann geht´s aber gleich wieder weiter. Daten sind bisher noch wenige drauf, da ich erst das Problem wegen der arbeitenden Platten beseitigen möchte.
Da ich sogesehn wegen meiner ersten NAS, die ich schon seit über 8 Jahre habe, ein alter Hase bin und auch in, hab ich schon einiges überprüft und nur das notwendigste eingeschaltet, aber die HDD´s laufen und laufen einfach vor sich hin.
Als Platten sind 2St. Seagate ST4000VN008-2DR166 verbaut und ne Speichererweiterung auf 8GB Ram hab ich der NAS noch gegönt.
Ich werd nun nochmal paar sachen testen.

Komischerweise wird bei den Prozessen nicht viel angezeigt, ab und zu sind einzelne mal bei knapp 10 % CPU Last, allerdings meistens sind sie unter 1 %. Wie man auf dem Screenshot sieht.

der HDD Spin Down ist leider so ein Thema, nutze verschiedene QNAP privat und auch auf der Arbeit. Hab das Problem schon in verschiedensten Konstellationen gehabt. Meistens waren es kaputt geupdatetete Apps oder die Firmware selber. In der Firma fast noch egal, ob der Spin Down klappt oder nicht, privat sehr störend.

Du kannst mit nem Script (wenn du mit SSH klarkommst) anzeigen lassen was den Spindown verhindert ->

https://wiki.qnap.com/wiki/Fin…hard_drives_from_spindown

ich würde allerdings als erstes mal eine ältere Firmware versuchen, bei mir ist es von 4.4.2.1270 build 20200410 bis 4.4.2.1302 build 20200512 so, dass der Spin hinüber ist (4.4.2.1310 build 20200519 dann wieder ok) also vielleicht mal die letzte 4.4.1 versuchen ... Das Problem scheint ja nicht auf allen Modellen aufzutreten evtl ist es bei etwas ganz anderes.

Danke, ich hab jezt auf die 4.4.1 downgegraded und das Script is am laufen.
Testweise hab ich den Timer mal auf 5 Minunten runtergesetzt, da is ab und zu zwar mal ruhe, nur im gesamten is es nicht viel anders.

Das Script bringt immer wieder folgendes:

11966.941200] jbd2/dm-0-8(3148): WRITE block 2147754168 on unknown-block(253,0) (8 sectors)
<7>[11963.869158] jbd2/md9-8(2313): WRITE block 829072 on unknown-block(9,9) (8 sectors)
<7>[11963.876155] md9_raid1(2300): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
<7>[11963.876184] md9_raid1(2300): WRITE block 1060216 on unknown-block(8,16) (1 sectors)
<7>[11963.918135] md9_raid1(2300): WRITE block 1060232 on unknown-block(8,0) (1 sectors)
<7>[11963.918157] md9_raid1(2300): WRITE block 1060232 on unknown-block(8,16) (1 sectors)
<7>[11963.938388] jbd2/md9-8(2313): WRITE block 829080 on unknown-block(9,9) (8 sectors)
<7>[11963.938442] jbd2/md9-8(2313): WRITE block 880968 on unknown-block(9,9) (8 sectors)
<7>[11963.938452] jbd2/md9-8(2313): WRITE block 880976 on unknown-block(9,9) (8 sectors)
<7>[11963.938471] jbd2/md9-8(2313): WRITE block 880936 on unknown-block(9,9) (8 sectors)
<7>[11963.938479] jbd2/md9-8(2313): WRITE block 880944 on unknown-block(9,9) (8 sectors)
<7>[11963.938497] jbd2/md9-8(2313): WRITE block 829016 on unknown-block(9,9) (8 sectors)
<7>[11963.938506] jbd2/md9-8(2313): WRITE block 829024 on unknown-block(9,9) (8 sectors)
<7>[11963.938518] jbd2/md9-8(2313): WRITE block 829032 on unknown-block(9,9) (8 sectors)
<7>[11963.938536] jbd2/md9-8(2313): WRITE block 828976 on unknown-block(9,9) (8 sectors)
<7>[11963.938545] jbd2/md9-8(2313): WRITE block 828984 on unknown-block(9,9) (8 sectors)
<7>[11963.938564] jbd2/md9-8(2313): WRITE block 523024 on unknown-block(9,9) (8 sectors)
<7>[11963.938572] jbd2/md9-8(2313): WRITE block 523032 on unknown-block(9,9) (8 sectors)
<7>[11963.938579] jbd2/md9-8(2313): WRITE block 523040 on unknown-block(9,9) (8 sectors)
<7>[11963.938633] jbd2/md9-8(2313): WRITE block 549592 on unknown-block(9,9) (8 sectors)
<7>[11963.938641] jbd2/md9-8(2313): WRITE block 549600 on unknown-block(9,9) (8 sectors)
<7>[11963.938647] jbd2/md9-8(2313): WRITE block 549608 on unknown-block(9,9) (8 sectors)
<7>[11963.938653] jbd2/md9-8(2313): WRITE block 549616 on unknown-block(9,9) (8 sectors)
<7>[11963.938659] jbd2/md9-8(2313): WRITE block 549624 on unknown-block(9,9) (8 sectors)
<7>[11963.938665] jbd2/md9-8(2313): WRITE block 549632 on unknown-block(9,9) (8 sectors)
<7>[11963.938671] jbd2/md9-8(2313): WRITE block 549640 on unknown-block(9,9) (8 sectors)
<7>[11963.938677] jbd2/md9-8(2313): WRITE block 549648 on unknown-block(9,9) (8 sectors)
<7>[11963.938683] jbd2/md9-8(2313): WRITE block 549656 on unknown-block(9,9) (8 sectors)
<7>[11963.938708] jbd2/md9-8(2313): WRITE block 549664 on unknown-block(9,9) (8 sectors)
<7>[11963.938714] jbd2/md9-8(2313): WRITE block 549672 on unknown-block(9,9) (8 sectors)
<7>[11963.938721] jbd2/md9-8(2313): WRITE block 549680 on unknown-block(9,9) (8 sectors)
<7>[11963.938744] jbd2/md9-8(2313): WRITE block 549688 on unknown-block(9,9) (8 sectors)
<7>[11963.938750] jbd2/md9-8(2313): WRITE block 549696 on unknown-block(9,9) (8 sectors)
<7>[11963.938756] jbd2/md9-8(2313): WRITE block 549704 on unknown-block(9,9) (8 sectors)
<7>[11963.941170] jbd2/md9-8(2313): WRITE block 549712 on unknown-block(9,9) (8 sectors)
<7>[11964.340150] md9_raid1(2300): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
<7>[11964.340179] md9_raid1(2300): WRITE block 1060216 on unknown-block(8,16) (1 sectors)
<7>[11964.430013] md9_raid1(2300): WRITE block 1060232 on unknown-block(8,0) (1 sectors)
<7>[11964.430036] md9_raid1(2300): WRITE block 1060232 on unknown-block(8,16) (1 sectors)
<7>[11966.966124] md1_raid1(2552): WRITE block 7794127504 on unknown-block(8,0) (1 sectors)
<7>[11966.966131] md1_raid1(2552): WRITE block 7794127504 on unknown-block(8,16) (1 sectors)
<7>[11967.355131] md1_raid1(2552): WRITE block 7794127504 on unknown-block(8,0) (1 sectors)
<7>[11967.355160] md1_raid1(2552): WRITE block 7794127504 on unknown-block(8,16) (1 sectors)

Meißt aber md1_raid1 oder md9_raid1. Kann das sein, das das RAID immer noch nicht fertig ist, mit dem synchen?

Bezüglich Spindown, Ich will eigentlich nicht unbedingt, das die Platten runterfahren, sondern einfach wenn kein Zugriff is, das sich die LEseköpfe auch mal still halten, denn ich muss leider doch sagen, die Seagate sind gegenüber den WD RED um einiges lauter beim Zugriff.

Ob das Raid noch synct siehst du unter Speicher in der Raid Verwaltung irgendwo. Wenn ich mir das so anschaue:

on unknown-block scheint mir das eventuell ein Problem mit einer Hdd oder dem Raid generell zu sein.

Sagt mir so aber jetzt nichts, Sorry.

Das hat soweit ich das beurteilen kann nichts mit dem Problem/Prozess hier zu tun, mach am besten mal einen neunen Thread auf, vielleicht weiß hier jemand im Forum dazu mehr...

HD Oberflächentest OK?

SMART 187/197 ok?

Ja da is alles ok, ich hab mir nun anderweitig beholfen.
Ich hab festgestellt, das des Gehäuse der TS-253Be die Plattengeräusche extrem verstärkt.
Gut wie schon gesagt die Segates sind um einiges lauter als die WD Red und das 6er Gehäuse is da um einiges stabiler gebaut, daher isind mir die Zugriffsgeräusche da nie aufgefallen.
Hab nun das Gehäuse etwas geöffnet und nun höhrt man die NAS auch fast nicht mehr und damit kann ich leben, denn es is ja auch klar, wenn sie was zu tun hat, dann muss ja auch auf die HDD´s zugegriffen werden.
Also is das Thema für mich vom Tisch, auch wenn ich überlege, ob ich nicht eventuell doch noch die Plastik-NAS gegen eine Metallerne 4er austausche.

Danke auf jeden Fall für eure Tipps und Hilfen.

Bei meinem TS-251B funktioniert der Spin-Down und hat meine ich immer funktioniert. Anscheinend läuft aber der Ventilator weiter (was aber vielleicht OK ist).

Ein Problem, das ich schon seit Einsatz des TS-251B habe, ist, dass es immer wieder passiert, dass mein Raspberry Pi mit Volumio immer wieder den Media-Server "verliert", vor allem nachdem irgendein anderes Gerät (z.B. Pioneer Netzwerk-Player) darauf zugegriffen hat. Dann nützt nur ein Neustart des LAN-Routers (D-Link DIR-652). "Verliert" heißt, dass der QNAP-Mediaplayer nicht mehr als Media-Server angezeigt wird, ein direkter Zugriff (z.B. auf eine Musik-Datei in der Playlist) ist aber nach wie vor möglich.