Hard resetting errors beim Erstellen eines Speicherpools mit bay 3-6. Fehleranalyse gemacht

  • Hallo!

    Ich bekomme bei meinem neuen TS-877 beim erstellen eines neuen Speicherpools mit den bays 3-6 (und nur bei diesen bays) hard resetting link errors.

    Ich habe die Platten getestet, es liegt definitv nicht an den Platten.


    Hier eine Übersicht der BAYS, damit ihr euch auskennt:

    bay-Übersicht.jpg

    Um den Fehler einzugrenzen bin ich so vorgegangen:

    1.) Nas neu initialisert mit nur 2 m.2 SSDs drinn. Mit diesen Speicherpool 1 (Raid1) erstellt und System-Volume angelegt. Kernel-Log-Analysator ausgeführt. keine Fehler.

    2.) Nas heruntergefahren. 2 SSDs in ssd-bay 1 und 2 eingelegt, 2 SSDs in disk bay 1 und 2 eingelegt, 4 wd red in disk bay 3-6 eingelegt.

    3.) NAS gebootet. Kernel-Log-Analysator ausgeführt. keine Fehler.

    4.) SSD-Cache (Raid1) mit den 2 SSds in den ssd-bays angelegt. Kernel-Log-Analysator ausgeführt. keine Fehler.

    5.) Storagepool 2 (RAID1) mit den 2 SSds in disk-bay 1 und 2 erstellt. Kernel-Log-Analysator ausgeführt. keine Fehler.

    6.) Storagepool 3 (Raid5) mit den 4 wd red in disk-bay 3-6 erstellt. Kernel-Log-Analysator ausgeführt. Fehler:

    kernel analysator.jpg

    In Systemprotokolle sieht man das:

    systemprotokolle.jpg

    Habe dann über putty nochmal überprüft, welche devices ata1 und ata2 sind. Ergebnis:

    Ata1 ist sda

    Ata2 ist sdb

    Dann in putty die Seriennummer von sda und sdb abgegriffen und und es handelt sich definitv um die 2 wd red in bay 3 und 4.

    (Diese Platten sind komplett neu und fehlerfrei). Da ich es auch mit anderen Platten getestet habe, kann ich einen Plattenfehler ausschließen.


    dmesg gibt folgendes aus: siehe Anhang: (konnte es nicht als Code-Block einfügen, weil zu lange.)


    Es ist auch so, dass die Fehler erst auftreten, wenn ich den Storagepool mit den wd red anlege (egal ob RAID5, RAID6 oder RAID10, es gibt immer hard resetting link Fehler). Wenn die Platten einfach frisch im NAS stecken, ohne dass darauf ein Storagepool bzw. RAID angelgt wird/ist, gibt es keine Fehlermeldungen. Beim Erstellen der anderen Storagepools gab es keine Fehler.

    Im QTS Speichermanager sind auch keine Fehler angezeigt. Nur (wie oben geschrieben) gibt es unter Systemprotokolle" diese NCQ Meldungen.


    Kann mir hier jemand weiterhelfen bzw. was dazu sagen? Hardwarefehler (schon wieder)?


    Interessant zu erwähne ist vielleicht noch, dass ich bei dem vorherigen TS-877 (das ausgetauscht wurde), neben anderen problemen auch ata1 und ata2 hard resetting Fehler hatte. Damals habe ich leider nicht überprüft, welche devices in welchen bays das waren, aber da die Platten gleich gesteckt waren, soweit ich mich erinnere, dürfte es auch damals bay 3 und 4 gewesen sein.


    Danke vielmals,

    lg Robertson23


    PS: Ticket bei Qnap ist gemacht.


    update:


    zusammengefasst:

    ata1 = sda =disk 4

    ata2 = sbd = disk 3


    habe NCQ bei beiden disks mittels:

    Code
    echo 31 > /sys/block/sda/device/queue_depth
    echo 31 > /sys/block/sdb/device/queue_depth

    manuell über putty aktiviert.

    Das ist auch in Systemprotokolle ersichtlich (habe testweise auch disable probiert und ein schneller smart test disk 4 habe ich auch gemacht, deswegen steht das auch drinn):

    ncq enable.jpg



    Bei beiden Disks ist es wieder auf diasabled (timeout error) gesprungen nach ein paar Minuten (disk 3 hat etwas länger mit Status enabled durchgehalten). Auch der Kernel Log hat bei ata1 (also disk 4) und ata2 (disk 3) den hard resetting link error um 1 raufgezählt:

    kernel2.jpg


    Nach dem hard reset ist ncq scheinbar wieder aktiviert auf den Platten, bis zum nächsten timeout.


    laut dem kernel log kommt zuerst der NCQ disable, daraus resultiert später der hard resetting link.


    Mir ist aber nicht klar, was die Ursache für das NCQ Problem ist. Vor allem, da in bay 5 und 6 die selben wd red stecken, die keine NCQ Probleme verursachen! Gefühlsmäßig würde ich ja wieder auf einen hardware Fehler des Qnap (backplane, Speichercontroller) tippen. Ich hoffe sehr stark, dass nicht.


    update:

    habe jetzt den storage pool gelöscht, und die platten umgesteckt. disk 3 und 4 auf 5 und 6 und umgekehrt, dann neuen storagepool raid5 angestoßen. synchronisiert gerade. sollte es am Qnap liegen, müssten die NCQ errors jetzt trotz der anderen Platten auf bay 3 und 4 auftreten und die ata errors sollten auch bei ata1 und ata2 bleiben.

    ata1 (disk 4) ist jetzt sdm

    ata2 (disk3) ist jetzt sdl

    sollte es an den Platten liegen, dann müssten die NCQ errors bei bay 5 und 6 kommen, und ata13 und ata 14 betreffen (ata14 = sda, ata13 = sdb).

    mir wird langsam schwindelig.


    update:

    verdammt. Eben ist bei disk 3 (ata2) wieder ein nrq error aufgetreten, obwohl da ja jetzt eine andere Platte drinn ist. disk 4 wird auch nicht lange auf sich warten lassen wahrscheinlich.

    Damit ist klar, dass es nicht die Platten sind, endgültig.

    Mann, was ist da los? Backplane defekt?



    HALLO? Niemand eine Idee, was da los ist?

    Könnte es am zusätzlichen RAM liegen? (denke ich eigentlich nicht.)

    Hat die ganze Serie TS-877 eine Macke?

    Gibt es hier noch andere TS-877-Besitzer, die berichten können, was bei ihnen los ist?

    Mit keinem Gerät in meiner Vergangenheit hatte ich dermassen viele Probleme wie mit dem neuen Qnap.

    Kann vielleicht jemand generell was zu der ncq-Problematik sagen? Wer hatte bei diesem oder einem anderen Qnap-Gerät auch einen ncq-disable auf Grund von timeout? Wie konnte das Problem behoben werden? bios-update vielleicht? (bei Windows ist doch ncq automatisch aktiviert, wenn AHCI im bios eingestellt ist, oder?)

    Bin auch nicht der einizige hier, der ncq-Probleme hat.

  • jerstmal danke für die Antwort. dachte schon, dass ich alleine bleibe hier.


    ja, habe ich. kann da eine Verbindung bestehen? Ich sehe den Zusammenhang nicht ganz und wenn da einer wäre, warum sind nur 2 bays davon betroffen?


    aber ok, ich werde das heute Abend testen. Da ich es eh total demontieren muss, um den ram zu entfernen, werde ich es gleich neu initialisieren.


    Der RAM sollte aber laut speicher.de (dort gekauft) 100% kompatibel mit meinem Qnap sein. sind 2 16 gb Riegel von Samsung, wenn ich mich nicht täusche.

    Aber ich teste es und werde berichten, könnte aber später werden, schaut so gegen 22Uhr nochmal hier rein.


    und wen es wirklich am RAM liegen sollte (was mir nur recht wäre): welche RAM sind den wirklich 100% kompatibel??? Glückssache und wen man auf Nummer sicher gehen will, nur die "Original"-Qnap aus dem Qnap store? würden 500 Euro kosten (32gb). Etwas teuer.

  • Ticket bei Qnap ist gemacht.

    Die zwei Zitate von dir fügst du gedanklich mal zusammen ...

    nur die "Original"-Qnap aus dem Qnap store?


    Sollte QNAP einen "Nicht-QNAP" Speicher entdecken, ist das Ticket schneller zu als du schauen kannst!

    Ob der RAM jetzt schuld ist oder nicht, ist erst mal egal, für das Ticket MUSST du ihn rausnehmen.

  • RedDiabolo


    Ich entferne den RAM ja heute und teste dann erneut. Bin mir aber zu 99% sicher, dass es nicht daran liegt. Ich glaube fast schon, dass die ganze Reihe 877 oder zumindest eine Charge eine Macke hat. Ich wäre aber hocherfreut, wenn es doch der RAM wäre.

    Ich werde also tauschen und testen, und wenn dann nichts mehr kommt, werde ich neu initialisieren und alles sauber neu einrichten und über Nacht den Storagepool synchronisieren lassen. Wenn dann bis morgen Abend immer noch alles gut ist, dann wars wahrscheinlich doch der RAM.


    Und btw: habe heute das kernel log und die Systemprotokolle der Qnaps in unserer Firma gecheckt. KEIN EINIZIGE NCQ timeout, und die logs reichen Jahr ezurück.

    Dann Kollegen angerufen, auch er hat auf 2 Qnaps keine NCQ errors im kernel log oder Systemprotokolle. Es ist abe rauch in keinem dieser Qnaps zusätzlicher RAM drinn,



    update:

    habe mich jetzt gleich, als ich nahc hause gekommen bin, dem Qnap gewidmet. Ram raus, alle Platten diskpart, neu initialisiert und gleich die neue firmware drauf. jetzt richte ich die Speicherpools wieder ein und berichte. es richtet gerade die default shares ein, wenn das fertig ist, lege ich die übrigen storagepools an und hoffe auf das beste. Ansonsten geht das teil morgen wieder retour. ich habe so ein rundum-sorglospaket mitgekauft um 100 euro, mit dem der Händler in den ersten 6 Monaten angeblich anstandlos sofort umtauscht, ohne dass man lange auf Qnap RMA warten muss. Hoffentlich hält diese Zusage, was sie verspricht.


    update:

    es bootet gerade wieder hoch mit allen Platten drinn.

    Was mir gerade noch geschossen ist: ist es theoretisch möglich, dass die PCIe karten (1 gtx1050, 1 gt1030, 1 asus 110gbit nic) zuviel Strom ziehen und das PSU (450 watt) da nicht mitacht? Eigentlich doch unmöglich, oder? DAS NAS ist ansosnten komlpett belegt mit Platten, also 2 m.2 sata ssds, 4 normale sata ssds, 4 wd red 4tb hdds. und eben die Karten. Das muss es doch mit 450 Watt lockerst packen.


    ok, jetzt sind alle storagepools angelegt und es synchronisiert den letzten pool raid 10 aus disk 3-6. bishe rnoch alle sgut. ich muss jetzt mal kurz weg, in ca 2 stunden sehe ich mir die Systemprotokolle und den kernel log an. Bin gespannt.



    update:

    bisher alles gut. Es deudet im Moment alles darauf hin, dass es wirklich der RAM ist bzw. war.


    immo2014

    sollte bis morgen alles so bleiben, schuld eich Dir zumindest ein Bier:* Ernsthaft, du kannst dir nicht vorstellen, wie große deine Hilfe war mit dem einen kleinen Hinweis. Ich hatte zwar ein posting drüber Richtung RAM gemutmaßt, aber alleine wäre ich nicht soweit gegangen, den RAM wirklich wieder zu demontieren. :thumbup::thumbup::thumbup::thumbup:

    Ich habe schon 100 mal gelesen, dass fremder RAM Probleme verursachen kann, aber dann , wenn es darauf ankommt, sehe ich den Wald vor lauter Bäumen nicht mehr.

    Danke (will den Tag aber nicht vor dem Abend loben, sieht aber sehr gut aus.)

    Sollte sich alles so bewahrheiten, weiss ich, was ich als nächstes kaufen muss. Original Qnap RAM (außer jemand hier kann einen Tipp abgeben).



    update:

    SO EIN MIST!
    Gerade heim gekommen. wieder hard reset disk 4, wieder wegen NCQ timeout. Es war also doch nicht der RAM! Wäre ja zu schön gewesen. Jetzt reichts mir. Gerät geht zurück!



    WICHTIGE FRAGE:

    Nachdem ich jetzt gerade mein TS-877 1700 abgebaut und wieder sauber für dien Rücktransport zum Händler verpackt habe, stellei ch mir folgende Frage:

    Kann es sein, dass das TS-877 (oder zumindest die in Österreich/Deutschland im Moment im Handel befindliche Charge) generell einen DOA-Defekt/generelle Störung hat? Ich habe jetzt 2 nagelneue TS-877 von unterschiedlichen Händlern (!) hinter mir, und beide waren ab Werk nicht in Ordnung! Ihr könnt mir glauben, dass ich beide Male die Teile wie rohe Eier behandelt habe, immer (total übertrieben) mit Antistatikband und geerdet gearbeitet habe usw. Was soll ich jetzt machen? Auf einen 3. Versuch ankommen lassen oder zum TVS-882 wechseln? Ich weiss ja nicht, wieviele TS-877 mittlerweile weltweit verkauft wurden, aber wenn es ein generelles Problem gäbe, dann wäre das doch bekannt, oder? Ich habe jedenfalls schon Bauchweh bei dem Gedanken, das 3. TS-877 einzurichten (obwohl es eigentlich mein Traum-NAS ist).

    Was würdet ihr machen?

  • Wenn ich zwei Geräte mit dem gleichen Fehlerbild hätte, wäre für mich die Serie verbrannt.


    Alles nur nicht das Modell, würde ich meinem Händler dann mitteilen.

  • hi,

    ja, ich habe den shop eben angeschrieben und gefragt, ob ich ein tvs 1282 i7 haben kann statt wieder ein ts-877. vielleicht habe ich mit einem intel gerät mehr Glück.

    update:

    ts-877 ist bereits am postweg retour.

    Es ist echt zum K****. Das TS-877 ist mehr oder weniger mein Traum-NAS, aber ich bekomme einfach kein funktionierendes. ich schau jetzt mal, ob de rHändler so kulant ist, und mich auf das tvs 1282 i7 wechslen lässt. allerdings hätte ich da gerne wieder die version mit dem i7-7700 und nicht den i7-6700. mit dem schwächeren PSU von 250 watt könnte ich ja noch leben bzw später selbst wechseln, aber so ne alte cpu? wobei 7. generation ja auch nicht gerade als neu bezeichnet werden kann.