Mac OSX: direktes Kopieren von NAS auf USB-Stick extremst langsam

[Frank E. (Firma: Q3) (qualidat)]

Ich wollte eine Datei von ca. 6GB mit meinem iMac vom NAS auf einen 
USB-Stick kopieren.

Während mir der Finder für die direkte Kopie (Ziehen von Fenster zu 
Fenster) eine Zeit von 48 Minuten anbot, was ich dann nach ca. 10 Minute 
abgebrochen habe, hat das indirekte Kopieren zunächst auf die Platte des 
iMac und dann auf den Stick keine 5 min gedauert ...

Wie ist das zu erklären?

Der iMac ist jetzt kein ganz neues Modell, aber immerhin ein 2,66 GHz 
Core2Duo mit 8GB RAM.

[Stefan F. (Gast)]

Läuft der Netzwerkanschluss zufällig indirekt auch über USB?

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hi,

ist es reproduzierbar, wenn du das direkte Kopieren jetzt noch mal 
probierst?

Welches Protokoll verwendest du für den NAS Zugriff? Bei beiden 
versuchen das selbe?

Viele liebe Grüße
Timm

[Frank E. (Firma: Q3) (qualidat)]

Timm R. schrieb:
> Hi,
>
> ist es reproduzierbar, wenn du das direkte Kopieren jetzt noch mal
> probierst?
>
> Welches Protokoll verwendest du für den NAS Zugriff? Bei beiden
> versuchen das selbe?
>
> Viele liebe Grüße
> Timm

Ja, das ist reproduzierbar. Es macht (gefühlt) keinen Unterschied, ob 
ich auf das NAS (Synology) per AFP oder SMB zugreife.

Scheint schon irgend ein "Knoten" im OSX zu sein oder im Chipsatz des 
iMac. Ist jetzt kein Drama, weil ich nicht oft so große Dateien kopiere, 
in dem Falle fiehl es eben besonders auf, weil ich es eilig hatte.

Ansonsten ist mein "Alter" schon ein sehr zuverlässiges Arbeitstier ...

[Frank E. (Firma: Q3) (qualidat)]

Stefanus F. schrieb:
> Läuft der Netzwerkanschluss zufällig indirekt auch über USB?

Nein, natürlich nicht. iMacs haben ein "richtiges" Ethernet-Interface. 
WLAN hat er auch, habe ich aber abgeschaltet. Es besteht Gigabit-LAN zum 
Switch und auch von dort zur Synology.

[Jim M. (turboj)]

Frank E. schrieb:
> Wie ist das zu erklären?

Zugriffe auf USB Sticks benutzen keinen Schreibcache, weil $User den 
einfach abziehen kann.

So können die unvermeidlichen Wartezeiten beim Schreiben aber die 
Netzwerk Performance beeinflussen, denn in den "Pausen" wird vom 
Netzwerk nix gelesen.

TCP braucht jeweils einen kurzen Moment um von "nix los" auf "full 
Power" hochzuschalten. Im Ergebnis gibt es ungünstige Kobinationen von 
Block-Größen (beim Kopieren) und Netzwerk Timing.

Lokale HDD oder SSD hat das Problem nicht, da gibts Schreibcache.

Abhilfe wäre zum Bleistift das mitgeliferte "dd" auf der Kommandozeile,
denn da kann man die Blockgröße beim Kopieren angeben:

> dd if=/Pfad/zum/Netz/File of=/Pfad/zum/Stick/File  bs=100m

Mit bs=100m kopiert man in 100MB Schritten, was bei USB 2.0 dann jeweils 
den Stick für ein paar Sekunden auslastet.