staging.inyokaproject.org

Hallo

Ich war vor kurzem gezwungen meinen Netzlaufwerk Zugriff (mehrere QNAP NAS) von NFS auf SMB/CIFS umzustellen, da QNAP es irgendwie hingekriegt hat, NFS auf ihrem neuen Betriebssystem kaputtzumachen.

Nachdem ich die ersten Tage das Gefühl hatte mit SMB laufe alles soweit normal, habe ich nun plötzlich ganz wirre Störungen.

Problemkomplex 1: Das Kopieren von Dateien auf den SMB-Share (konkret von einem SMB Share auf einem NAS zu einem SMB Share auf einem anderen NAS) scheitert in vielen Fällen. Vor wenigen Tagen habe ich noch Problemlos grössere Datenmengen kopiert, aber nun kriege ich ständig Fehler, wobei diese nicht völlig konsistent reproduzierbar sind. Beispiele:

- Ein grösseres File habe ich ca. 5 Mal zu kopieren versucht. Jedes Mal hat es dem Anschein nach die komplette Datenmenge kopiert, nur um dann zum Schluss zu sagen "Fehler: ... kann nicht geschrieben werden", worauf hin die Datei auf dem Ziel wieder verschwindet.

- Einen Ordner mit mehreren relativ grossen Files konnte ich ebenfalls wiederholt nicht kopieren, wobei in manchen Versuchen zumindest die erste Datei kopiert wurde und es erst bei der zweiten zum Fehler kam, in anderen Versuchen (selber Ordner) kam der Fehler schon bei der ersten Datei.

- Handkehrum konnte ich eine andere, mittelgrosse Datei dann wieder im ersten Versuch problemlos kopieren

Das grössere File aus dem ersten "Beispiel" habe ich auch noch in der Konsole via cp zu kopieren versucht. Es resultierte in folgendem Fehler: "cp [...] konnte nicht geschlossen werden: Datenübergabe unterbrochen (broken pipe)" Allerdings bleibt das File dann im Ziel erhalten (anders als wenn ich mit dem GUI kopiere), wobei sich zeigt, dass sich das File im Ziel öffnen lässt und auch exakt die selbe Anzahl Bytes hat wie das Original. Per Zufall bin ich dann aber darauf gestossen, dass das File (es handelt sich um ein Video) tatsächlich einen kleinen "Hickup" an einer Stelle hat, den das Original nicht hat. (Vielleicht sind es auch mehrere Hickups, ich hab halt einen gefunden.)

Problemkomplex 2: Haufenweise Ordner sind manchmal einfach im Dolphin Dateimanager nicht da. Jetzt habe ich beispielsweise gerade einen Ordner geöffnet, von dem mir 136 Unterordner angezeigt werden. Tatsächlich hat dieser Ordner aber über 500 Unterordner. Nachdem mir dies das erste mal aufgefallen ist, habe ich unmounted und wieder mounted, da waren wieder die 500+ Ordner da. Nun, ein paar Stunden später sind wir aber wieder bei 136. Und dieses Mal hilft auch mehrfaches remounten nicht. Dafür sind die 500+ (gemäss Fusszeile des Dolphin Dateimanagers) vorher für wenige Sekunden "aufgeblitzt", nur um danach gleich wieder weg zu sein. Wenn ich in der Konsole "ls" im Ordner ausführe, erhalte ich alle 500+ Unterordner angezeigt. Wenn ich mit mkdir einen neuen Ordner anlege, sind danach (Zufall?) in Dolphin auch alle Ordner wieder zu sehen. Nach dem Löschen des besagten Ordners sind's dann wieder 136... (also wohl kein Zufall sondern Wahnsinn...)

Nun wenn man etwas nicht gebrauchen kann, dann sind es natürlich Unzuverlässigkeiten was den Datenbestand und das Lesen/Schreiben/Kopieren von Daten angeht, deswegen muss ich der Sache hier auf den Grund gehen. Die Frage ist nur: wie diagnostiziert man das?

In Journald finde ich gelegentlich:

kernel	CIFS: VFS: \\192.168.1.15 Send error in SessSetup = -11

sowie

kernel	CIFS: VFS: \\192.168.1.12 Error -32 sending data on socket to server

wobei die beiden zeitlich nicht zwingend mit Kopierfehlern korellieren

Zeitlich mit dem Kopiervorgang korreliert hingegen Haufenweise vom Folgenden (allerdings nur wenn via Dolphin kopiert wird, bei cp nicht):

kernel	CIFS: VFS: source and target of copy not on same server

(Wird als "Error" geloggt, ist aber letztlich einfach eine zutreffende Beschreibung des Sachverhalts: Quelle und Ziel befinden sich tatsächlich auf verschiedenen NAS.)

Was ich schonmal probiert habe, ist cache=none als Mountoption zu setzen. Auf Problemkomplex 2 scheint es keinen Einfluss zu haben. Bezügl. Problemkomplex 1 führt es zunächst einmal dazu, dass sich die Transfergeschwindigkeit auf weniger als ein Drittel reduziert, dafür aber bei einem ersten Test keine Fehlermeldung beim Kopieren mehr auftauchte. Allerdings liess sich das kopierte File anschhliessend nicht öffnen... hier werde ich morgen noch mehr testen.

Moin, leider hast du wichtige Informationen nicht genannt:

• Alle deine Tests hast du mit ETHERNET gemacht und NICHT mit WLAN?

• Die QNAP Systeme sind alle mit der Aktuellsten Update Version und NICHT veraltet?

• Um welche QNAP Modelle handelt mit welcher Firmware Version?

• Was sagt der QNAP Support oder hast du geschaut ob es bekannte Probleme gibt, z. B. QNAP Forum?

• Welches Ubuntu Version setzt du genau ein?

• Wie ist dein Netzwerk aufgebaut, handelt es sich um ein Firmen Netzwerk oder ein Privates (wie komplex ist der Netzwerkaufbau, z. B. sind Unterschiedliche VLANS genutzt usw.)

• Was passiert, wenn du alternative übertragungsverfahren (rsync, scp, sftp) versuchst, hast du dann auch Abbrüche (direkt übertragen zwischen den QNAP Systemen)?

• Alle deine Tests hast du mit ETHERNET gemacht und NICHT mit WLAN?

Ethernet

• Die QNAP Systeme sind alle mit der Aktuellsten Update Version und NICHT veraltet?

Exakt

• Um welche QNAP Modelle handelt mit welcher Firmware Version?

TS-473A mit QuTS hero h5.1.5.2680

TS-133 mit QTS 5.1.5.2679

Das ist die jeweils aktuelle Version.

(Es existiert noch ein drittes, älteres QNAP, da sollte hier aber nichts zur Sache tun, da die Probleme auch ohne dessen "Beteiligung" auftreten.)

• Was sagt der QNAP Support oder hast du geschaut ob es bekannte Probleme gibt, z. B. QNAP Forum?

Meine frühere Erfahrung mit dem QNAP-Support ist, dass die Antworten da 1+ Monate auf sich warten lassen und dann nicht zwingend viel zur Problemlösung beitragen.

Die QNAP Foren habe ich noch nicht intensiv durchforstet.

• Welches Ubuntu Version setzt du genau ein?

Kubuntu 22.04, aktuellster Patchstand

• Wie ist dein Netzwerk aufgebaut, handelt es sich um ein Firmen Netzwerk oder ein Privates (wie komplex ist der Netzwerkaufbau, z. B. sind Unterschiedliche VLANS genutzt usw.)

Privat. Nicht sehr komplex. Keine VLANs. Die beiden NAS hängen am selben Switch. Dieser ist mit einem Kabel mit dem Router (mit integriertem Switch) verbunden, an welchem mein PC hängt.

• Was passiert, wenn du alternative übertragungsverfahren (rsync, scp, sftp) versuchst, hast du dann auch Abbrüche (direkt übertragen zwischen den QNAP Systemen)?

Ich habe vot ca. 1-2 Wochen mit RTRR (proprietäres QNAP Übertragungsverfahren) grosse Mengen an Daten vom älteren (dritten) NAS aufs neue TS-473A übertragen. Das hat funktioniert.

Übrigens: ich habe gestern als letztes ja auf dem Linux PC "cache=none" in die fstab gesetzt. Dies reduziert wie gesagt die Transfergeschwindigkeit drastisch (auf unter 30MB/s), wirft aber keine Kopierfehler mehr aus.

Die grosse Datei die ich gestern so übertragen habe, liess sich dann anschliessend auf dem PC nicht mehr öffnen. Heute lässt sie sich jedoch öffnen und scheint auf den ersten Blick fehlerfrei zu sein.

Ich habe soeben zwei weitere recht grosse Dateien so übertragen, auch diese werfen keinen Fehler beim Kopieren und lassen sich anschliessend direkt öffnen.

Danach habe ich probeweise das "cache=none" wieder rausgenommen und nochmal getestet - und siehe da: beim selben File wieder das ursprüngliche Problem.

Wir können also vermutlich festhalten: Problemkomplex 1 lässt sich "umgehen", indem man die Shares auf dem Client mit cache=none mounted. Allerdings halt zu einem ziemlich hohen Preis, man opfert über zwei Drittel der Übertragungsgeschwindigkeit.

Problemkomplex 2 scheint davon übrigens wenig beeindruckt... ob ich nun die 136 oder die 500+ Unterordner sehe, ist weiter "mal so mal so".

im Terminal werden alle Verzeichnisse angezeigt? Ich könnte mir vorstellen das es nur ein anzeige Problem (bug) ist. Ich setze meist Ubuntu in der Server variante ein ohne GUI. Kopierst du die daten übers Terminal oder über die GUI?

Normalerweise kopiere ich übers GUI.

Und wie bereits gesagt:

- Verzeichnisinhalt wird übers Terminal korrekt angezeigt (zumindest bei meinen bisherigen Tests), übers GUI nicht zuverlässig

- Kopieren wirft sowohl über GUI wie auch Terminal Fehler (es sei denn ich setze cache=none und reduziere damit die Transfergeschwindigkeit auf etwa 30% des Soll-Werts)

Das mit dem Verzeichnisinhalt könnte wohl ein Problem des Dateimanagers (Dolphin) sein, der ist ja seit ca. 2 Jahrzehnten nicht dazu in der Lage, die Inhalte von Verzeichnissen zuverlässig zu zählen (anzuzeigen allerdings normalerweise schon). Das mit den fehlschlagenden Kopiervorgängen wird aber wohl ein tiefer seitzendes Problem sein.

Also da du auf dem QNAP ZFS nutzt, wieviel RAM hast du im NAS Verbaut und wieviel Festplatten Speicher hast du im NAS verbaut?

8GB RAM, RAID 5 aus 4x 20TB (bzw. was die Festplattenhersteller als TB angeben), also etwa 52TB Nutzkapazität.

Die RAM-Auslastung schien mir während der Kopiervorgänge aber nie auffällig.

Ich bin mr nicht sicher, ich setze TrueNAS ein und da gibt es eine Faust Formel wieviel RAM man haben sollte. Ich habe auf meinem System 64GB Ram. Ich habe keine Ahnung, ob QNAP den RAM nutzt, um den Inhalt zu catchen. Deshalb würde ich auf alle Fälle den RAM VOLL ausbauen. Keine Ahnung, ob es deinem Problem hilft. Also wie du ja geschrieben hast, würde es mit cache=none laufen, könnte es das nicht die Richtung sein, zu wenig RAM zum cachen? Ich persönlich würde ja doch mal den Support fragen ob es daran liegen kann

cache=none betrifft meines Wissens das Caching auf dem Client, nicht auf dem Server

Ich denke das Problem ist eher bei der SMB Implementierung zu suchen.