Probleme beim Kopieren grosser Dateien mit SMB (QTS: 5.0.1.2376):

Ich migriere etwa 35TB daten von meinem alten TS-853a NAS auf mein neues TS-832PX migriert.

Nun bin ich fast am Ende und kopiere einen Satz Backups (3TB) von einem Windows server (2016) auf das NAS. Ziel: ein thin Volume auf dem Qnap NAS

Netzwerk ist mit 10GBE (intel X520 bei Server, eingebaut bei NAS), verbunden über DAC Kabel und einen Switch.

Die Kopie, die wird aber nicht ordentlich fertig. Stattdessen sagt mir Windows dass ein unerwarteter Netzwerkfehler aufgetreten ist (Im Windows Protokoll sind aber keine Abbrüche der Netzwerkverbindung sichtbar). Auf dem NAS im log.smb kommen Meldungen wie:

[2023/05/13 10:24:48.400444,  0] ../../source3/modules/vfs_time_audit.c:46(smb_time_audit_log_msg)
  WARNING: VFS call "fallocate" took unexpectedly long (819.46 seconds) filename = "/share/CACHEDEV3_DATA/xxx/Altaro/AltaroV7S/f96cb1ac-cc1f-43fc-aaec-a2b2624ad373/Data/D008.altrdf" -- Validate that file and storage subsystems are operating normally

Die Fehler betreffen grosse Dateien: 150-600Gb gross.

819 Sekunden. Das ist lang, zugegeben. Andere Meldungen sind 120, oder ähnlich. die 819, die sind ein bisschen ein Ausreisser.

Das Ziel für die Kopien, das ist ein Raid-5 mit 3 8TB 5400 Disks. Das sind lahme platten. Aber die könnten schon 100MB/s. Die Disks sind unauffällig (zumindest ein kurzer smart Test ist gut).

Die CPU ist unterbeschäftigt. wartet meist auf I/O (des Disksubsystems nehme ich an).

Den Ram hatte ich auch 16GB erweitert und der ist zu 80% mit Cache belegt. Also genug frei.

Bei einem thin Volume, muss beim Schreiben neuer Daten natürlich immer das Volume erweitert werden. Das kostet Zeit. Daher habe ich das thin Volume gelöscht und ein thick Volume genommen.

Das Fehlerbild bleibt aber weiterhin identisch.

Schliesslich habe ich den Kopierjob geändert: robocopy statt mit MT:8 mit MT:1 - nur noch ein Kopierthread statt acht. Mal kucken was dabei rauskommt.

Ich bin damit einverstanden, dass man mir vorwirft langsame Festplatten in einem langsamen NAS zu verwenden. Dann geht es eben nicht so schnell (Ich habe mal einen Test des Raids gemacht, da kamen immerhin noch >100MB/s raus, Man sieht auch am Netzwerktraffic, dass das in etwa erreicht wird).

Aber nicht einverstanden bin ich damit, dass man einfach keine grossen Dateien kopieren kann. Warum ein Abbruch, warum nicht warten? Windows ist geduldig und wartet gerne beim kopieren. Egal ob ein oder 8 Kopier-Threads.

Ich erinnere mich daran einmal das QTS 5.1 getestet zu haben - ich wollte wissen ob ein neueres OS langsamer oder schneller ist. Das habe ich dann sofort wieder deinstalliert, denn da hatte ich ein ganz ähnliches Problem beim Testen. Leider habe ich da nicht im NAS die Logs angeschaut.

Meine Fragen:

Ist meine Auffassung eventuell falsch, dass, unabhängig von der Performance des Ziels eine Kopie über das Netzwerk möglich sein sollte?

Hat jemand schon etwas ähnliches erlebt?

Betrifft dieses Problem vielleicht aber nur Modelle mit ARM Chipsatz? Ich fand, mein altes TS853a, das war diesbezüglich fehlerfrei (auch mit OS 5.0.1).

Gibt es vielleicht einen Schalter den man setzten kann damit das NAS etwas mehr Geduld hat mit sich selbst?

Sollte ich vielleicht ein Downgrade auf die Version 4.x probieren?

Danke.

Hi BE,

Robocopy sagt:

2023/05/13 12:20:36 ERROR 59 (0x0000003B) An unexpected network error occurred.

Mit MT:1 da habe ich die erste Datei die mit MT:8 nicht kopiert werden konnte kopieren können. Auch das smb monitoring hat auf dem NAS seither keine Fehler mehr gemeldet.

Mit nur einem Kopierthread ist das natürlich langsamer.

ich teste jetzt mal weiter mit MT:2 um ein Optimum zu finden bei dem noch keine Fehler auftreten.

Aber das löst nicht das Problem, Denn es kann ja ohne weiteres mal vorkommen dass andere Programme hartnäckig versuchen mit aller Kraft Daten auf das NAS zu senden.

danke für die Ideen.

Es scheint (wohlgemerkt: scheint) nun plötzlich zu funktionieren.

Vielleicht weil eine NAchricht des NAS kam (2H nach der erstellung des thick Volumes):

Message: [Storage & Snapshots] Finished ext4lazyinit. Volume: DataVol2, Storage pool: "1".

Ich hatte gewartet nach der Erstellung des Volumes bis dort bereit stand.

Aber ich habe nachdem die Nachricht kam nochmals den kopierjob neu gestartet, wieder mit acht threads. Bislang keine Fehlermeldungen!

Leider muss ich das erstmal stoppen denn nun starten die Datensicherungen.

Es wäre schön wenn es jetzt tut. Das internet, das hat nämlich noch einen anderen Tip parat: RAM tauschen. Bei jemand der wie ich den Ram erweitert hatte mit einem Fremdprodukt, da brachte der Rücktausch nämlich den Fix. Das wäre sehr unerfreulich, denn dann hätte das NAS vielleicht seit einer Woche ein paar Bitfehler in meine Sicherungen eingebaut. Leider bin ich zu arm für ein NAS mit ECC Ram. Fast hätte ich einfach einen gebrauchten Server genommen, der kostet nämlich auch Euro 1000 (z.b. ein R730). Und hat viel mehr CPU viel mehr RAM und auch ECC-Ram und es läuft Windows drauf -eigentlich besser als jedes NAS. Nur, der braucht 150W, und das NAS braucht nur 70W. Also hab ich das NAS genommen.

CR: ich habe eigentlich nicht mehrere Änderungen gleichzeitig gemacht (der Ram, der war schon von anbeginn drin für eine woche) oder was meinst Du damit?

Was aber die robocopy fehlermeldungen angeht: Du denkst somit, dass meine Überzeugung: kopieren muss möglich sein, wenn auch langsam falsch ist? Denkbar, aber ich bin nicht so leicht davon abzubringen. An anderer Stelle funktioniert das ja auch.

Während das NAS auf I/O wartet sollte es sich nicht tot stellen - stattdessen hat es aber >120sec (Vermutung, 120sec ist die zeit fürein TCP Timeout bei Windows), keine Anfragen aus dem Netzwerk mehr angenommen woraus Windows geschlossen hat, das NAS ist abgeschaltet.

BE: ich hatte bei der Erstellung des Think volumes gewartet bis es bereit war. Dass eine weitere hintergrundinitialisierung (sowohl bei thin als auch think volumes zusätzlich stattfindet die nicht angezeigt wird und nur bei Fertigstellung per Email mit geteilt wird, das war mir nicht bekannt, aber ich werde mal lesen gehen.

Aber unanhängig davon uch hier bin ich der Überzeugung, dass sich das NAS nicht tot stellen sollte, wenn es schon unbeschäftigt ist weil es auf I/O wartet. Zumindest sollte das dokumentiert sein.

Ich habe gestern noch zwei weitere 14TB Disks eingebaut und ein Raid-1 (kein lvm management) eingerichtet.

Prompt ist der Fehler wieder da. Aber selbst wenn man sieht dass im Hintergrund noch eine Aufgabe erledigt wird sollte eine kopie möglich sein. noch dazu werden Festplatten initialisiert die gar nicht Ziel für die Kopie sind. Die CPU ist <10%, Ram <20%. Ich denke, das ist einfach eine schlechte Implementation des Tasks der für die Initialisierung der Volumes zuständig ist. Anstatt beim warten anderen Prozessen Zeit zu geben, wird das System blockiert.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Crazyhorse

Wird ein QTS ein neues Volumen gefunden und ein gehangen, werden kurz alle Dienst neu gestartet.

ich habe aber meinen Kopierjob gestartet nachdem die die neuen Disks eingebaut waren und die initialisierung schon begonnen hatte.

klar,

Weder dieses NAS noch die Disks sind top Tier der Technik.

Das sind aber alles ganz normale Vorgänge. Die dürfen nicht dazu führen dass ein Kopiervorgang nicht möglich ist. Der dauert dann länger, aber möglich sollte es sein.