QTS 4.5.2.1630 build 20210406

  • Also warum nicht?


    Weil du doch schon Probleme hattest nachdem du diese getestet hast und es nicht zwingend nötig ist, warte doch bis zur nächsten oder übernächsten bis keine Probleme gemeldet werden, nun hast du ein System was nicht richtig läuft, hättest du aber nicht haben müssen.


    Oder aber teste weiterhin sofort und setze das QNAP ab und an neu auf, auch ok

  • und setze das QNAP ab und an neu auf, auch ok

    Neu Aufsetzten ist halt Arbeit.

    Ich nutzte die Gelegenheit zum neu Aufsetzen um gleich von statisch Volum auf Speicherpool umzustellen.


    Ob das eine gute Idee ist ohne vorher das Forum befragt zu haben? ;)

  • Ich habe nach der FW Aktualisierung auf meinem TS453D ebenfalls das Problem, dass nach Ändern der MTU das NAS nicht mehr erreichbar ist

  • So ich habe auch mal ein Update auf meinem alten TS-451 gewagt. Scheint so weit zu laufen. Allerdings funktioniert nach wie vor die SAMBA Freigabe nicht. Jedenfalls nicht über VPN.

    War zuvor aber auf Version 4.5.1.1540 build 20210107

  • QTS 4.5.2.1630 Build 20210406 installiert (Anfang April) auf TS653pro

    Ergebnis: alle NFS- mounts sowie iSCSi-Verbindungen meiner DebianServer sowie ESXi-Hosts kaputt

    rsync von QNAP zu anderen NAS bricht mit IOerror nach einiger Zeit ab

    zum Teil friert auch die Console sporadisch ein wenn ich Commands absetze


    DAHER: downgrade auf 4.5.2.1566 (die 1594er machte auch Probleme)

    Aber das Phänomen besteht noch immer - kein produktiver Einsatz möglich


    Versuche zur Zeit noch immer verzweifelt meine Daten auf einen anderen NAS zu schaufeln, aber die rsyncs brechen immer mit io-error ab


    ist eine MTU von 9000 angebracht? Netzwerkanschlüsse sind gebondet 2 x 2 bond0/1


    Wie weit soll ich noch downgraden?

    Könnte auch ein Hardwaredefekt vorliegen?

  • Stelle die MTU auf die Default 1500 und alles wird wieder laufen.

    Die 1630 hat wohl ein Problem mit Jumbos.

  • In meinem Fall war glücklicherweise ein Downgrade auf 4.5.2.1605 problemlos möglich und somit auch die Einstellung des MTU auf 9000

  • Leute, wenn euch sowas auffällt, wie z.B. dass es Probleme mit den Jumbos gibt, bombadiert den QNAP Support mit Tickets, die sollen mitbekommen, dass die FW Entwickler regelmäßig Mist bauen =)

  • downgraded auf 1566, MTU auf 1500, reboot


    rsync auf anderes NAS, nach ein paar GB kommt diese Meldung:

    Code
    client_loop: send disconnect: Broken pipe
    rsync: writefd_unbuffered failed to write 4092 bytes to socket [sender]: Broken pipe (32)
    rsync: connection unexpectedly closed (168 bytes received so far) [sender]
    rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]


    ???


    stelle nun auf allen Systemen (auch Switche) die MTU auf 1500 und versuche es nochmals

  • Nach einem Upgrade auf die 1630 beim TS-473 mit der QXG-10G1T waren nur noch die Activity LEDs an der Netzwerkkarte an, aber kein Zugriff möglich. Nach dem FW-Update auf der QXG, funktionierte wieder alles

  • nach dem downgrade kämpfe ich mit dem Energiezeitplan. Weder das Einschalten zu einer bestimmten Uhrzeit/Tag also auch das geplante Ausschalten funktionieren nicht mehr.

    Für gewöhnlich lasse ich den Server täglich um 0 Uhr herunterfahren und um 6 Uhr wieder hochfahren.


    EDIT: Hat sich auch erledigt. Ich Dummkopf habe ich natürlich vergessen die Systemzeit des NAS korrekt einzustellen.

    Einmal editiert, zuletzt von mg8980 ()

  • downgraded von 1630 auf 1566 wegen unzufriedenheit.

    nun spinnt das qnap ts 653 pro total.


    das zurücksetzen der mtu von 9000 auf 1500 brachte nicht den gewünschten Effekt.


    wenn ich nun das NAS über die Weboberfläche beenden will passiert genau nix, auch über die console mit /sbin/halt passiert nix, hilft nur manuel auschalten.

    beim start danach wartet man ewig bis qboost gestartet ist, vorher kann man nix im speichermanager machen (Filesystemcheck!)


    jetzt wollte ich auf 1540 downgraden, aber der prozess meint, ich müsste zuerst den ssd-cache deaktivieren und löschen.

    ich kann zwar den hebel auf OFF stellen, es passiert aber genau nix -> Anzeige bei "Cacheinhalt wird gelöscht" bleibt bei 0% (warte schon 45 Minuten)


    ???


    die Gacke ist jetzt schön langsam am Dampfen.

    Ich kann mein vCenter auf einen ESX nicht starten weil die vm-discs auf den 653pro als nfs eingebunden sind und der NFS&iSCSi-Zugriff nach dem Upgrade auf 1630 nicht mehr korrekt funktioniert :(


    Also: Downgrade geht nicht weil SSD-Cache geleert werden muss -> geht aber nicht - > 0%

    Sichern der Dateien auf ein anderes NAS geht nicht -> rsync error

    Console ist jetzt gerade nach der Eingabe von ls -la im /share Verzeichnis eingefrohren


    Ich forsche weiter