Schreiben auf QNAP-NAS mit Windows verursacht defekte Daten.

  • Danke für die Aufklärung. Die Fehler sind schon vor dem Write Cache aufgetreten.
    Wenn ich einen PC mit den selben Kabeln direkt am Switch anstecke, kamen keine Fehler.
    Sobald das Switch dazwischen ist, kommen die Fehler.
    Wenn ich eine PCI-Karte mit gleichem LAN-Chip(QXG-10G1T) einbaue und verwende, kamen keine Fehler. (noch nicht über längere Zeit getestet)
    Beide Geräte wurden ausgetauscht. Ohne Erfolg.
    Das ist ja das Seltsame:
    Irgendwie ist nur die Kombination Switch+interner NAS-LAN-Chip das Problem, glaube ich. Aber ein Defekt ist es anscheinend auch nicht, weil es unwahrscheinlich ist, dass die ausgetauschten Geräte die selben Defekte haben.

    Arbeitsspeicher wurde nie geändert.

  • Mir fällt übrigens auch auf, dass das Qnap Protokoll immer noch voll von gedropten Paketen ist. Ist das normal?

    Nein, im LAN ist das nicht normal (außer die Gegenstelle reagiert nicht, da z. B. nicht eingeschaltet). Da sollte die Kommunikation ohne Paketverluste vonstatten gehen.

    Ich habe es ja schon an verschiedene Switches(selbe Modell)

    Das lässt mich gerade aufhorchen, da ich hier ein Problem hatte, bei dem es an der Software des Switches (der war von QNAP) lag. Es gab massive Paketverluste, und außer einem langsamen Ping ging nichts. Ich hatte andere Ports probiert, Kabel getauscht, keine Änderung, anderen Switch (gleiches Modell), aber gleicher Fehler, dann einmal PC (ist ein MacBook mit Thunderbolt-Adapter für 10GbE) und NAS direkt verbunden, und plötzlich ging es. Mit dem Switch eines anderen Herstellers (Mikrotik) war das Problem wie weggeblasen. Es lag an der Software des Switches, weswegen der Austausch gegen ein anderes Exemplar des gleichen Modells nichts gebracht hatte.


    Was mir sonst noch als Fehlermöglichkeiten einfällt:

    - Defekte Kabel oder Stecker, Kabelbruch

    - Kabel außerhalb der Spezifikation (z. B. nur Cat 5 oder zu lang)

    - Störungen im Kabel, z. B. durch eine parallel führende Stromleitung (betrifft nur Kupferkabel)

    - Defekte 10GbE-Adapter im PC/NAS

    - Defekte SSD/Festplatte im NAS

    - Hardwaredefekt im NAS/PC/Switch (hast du wohl schon ausgeschlossen)

    - Fehlerhafte Software


    Was du testen solltest:

    - Direktverbindung PC zu NAS ohne Switch dazwischen. Wenn's geht, steht der Switch im Verdacht.

    - Verbindung mit Gigabit-LAN statt 10GbE: Wenn's geht, scheidet die SSD im NAS als Fehlerursache aus.

    - Verbindung über Switch, aber außer PC und NAS kein weiteres Gerät eingesteckt.

    - Kabel tauschen, Ports tauschen.


    Noch eine Nachfrage: Welche Kabel hast du (Kupfer oder LWL) und wie lang sind die?

  • Noch eine Nachfrage: Welche Kabel hast du (Kupfer oder LWL) und wie lang sind die?

    Ist Kupfer. Cat6a Hatte auch schon super kurze direkt an Switch + NAS probiert. Selbe Fehler, wenn Switch an Onboard-LAN.
    Bei nur Gigabit sind keine Prüfsummen-Fehler aufgefallen.

  • Wenn ich einen PC mit den selben Kabeln direkt am Switch anstecke, kamen keine Fehler.

    Bei 10GbE direkt über Wand-Verkabelung von einem kleinen Zimmer ins Nachbarzimmer. Also NAS-PC ohne Switch.
    Dabei sind mir nie Fehler aufgefallen.

    Auch im Qnap-Protokoll sind nur ganz wenige Dropped Pakete (4 von 19190381)


    Code
    eth0      Link encap:Ethernet  HWaddr 24:5E:BE:4D:AE:BD
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:19190381 errors:0 dropped:4 overruns:0 frame:0
    TX packets:19138709 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:28490630700 (26.5 GiB)  TX bytes:28491625153 (26.5 GiB)
  • Bei 10GbE direkt über Wand-Verkabelung von einem kleinen Zimmer ins Nachbarzimmer. Also NAS-PC ohne Switch.
    Dabei sind mir nie Fehler aufgefallen.

    Wenn sich das bestätigt - ich weiß jetzt nicht, wie schnell die Fehler bei dir auftreten, damit du sagen kannst, geht oder geht nicht - dann könnte wirklich ein Kompatibilitätsproblem mit dem Switch vorliegen, und in dem Falle würde ich einmal einen Switch eines anderen Herstellers ausprobieren (notfalls Internet-Bestellung, und wenn der Switch des anderen Herstellers das Problem nicht behebt, dann innerhalb der 14 Tage zurückschicken - vielleicht hast du aber auch einen Händler vor Ort, der leihweise aushelfen kann).

  • Hier mal meine Logs:

    Zum Testen habe ich meinen Dokumente Ordner vom NAS runter und in einen anderen Freigabeordner wieder hochgeladen (32,8 GB 11.967 Dateien). Also vom TVS-872XT zu meinem PC und zurück.


    Vor dem Test:

    Nach dem Test:

    Dabei gab es wohl 27 drops. Dabei ist aber auch nicht gesagt ob die dropped packages wirklich aus dieser Verbindung stammen. Meine Switches zeigen keine Fehler.

    Solange es nur drops sind und keine errors ist das aber erstmal nicht so schlimm (also in meinem Fall, bei dir sind es ja doch um einiges mehr). Meine Dateien sind alle heile.


    Meine Verkabelung kannst du hier nachlesen: Post #92.

  • Aber selbst dein packet loss liegt noch weit unter 1%. Normalerweise wird bei TCP das Paket dann einfach nochmals angefordert. Ich denke eigentlich weniger das der packet loss dein Problem ist. Er wird wohl eher ein Symptom sein.

    Da wir ja doch einen recht ähnlichen Aufbau haben würde ich auch erstmal auf den Switch tippen.

  • Dann tausche mal den Schrottgear gegen Miktrotik, HP, Cisco, Dell, TP-Link oder was anderes gescheites aus.


    Denn hier hast du die Fehlerquelle gerade selber benannt.


    Alternativ Ticket beim Hersteller aufmachen und hoffen das die das Nachstellen und eine neue Firmware schreiben können oder dir das Geräte tauschen da die Revision einen Hardware Fehlerhat.

    Da sollte ja noch Garantie drauf sein.

  • Weil ich seit einiger Zeit dasselbe Problem habe und jetzt auf diesen Faden gestoßen bin: als Überbrückungslösung funktioniert bei mir das Aktivieren der "Flow Control", einmal im (managed) Switch, einmal am PC in den Einstellungen für den NIC. Führt aber leider zu deutlich geringeren Geschwindigkeiten, was mich an der Sinnhaftigkeit von 10G bei meiner QNAP (in Verbindung mit QM2-2S10G1TA) zweifeln lässt.


    Vielleicht hat jemand in der Zwischenzeit noch eine weitere Lösung gefunden?