Hallo,

ich habe ein NAS DS1618+ von Synology mit DSM 6.2.3-25426 Update 2 mit SMB Dateifreigabe als Server in meinem Büro.

Funktioniert eigentlich ganz gut. Schreib-Lesevorgänge von den Netzwerk Macs auf den NAS sind ausreichend schnell.

Seltsam jedoch: wenn ich einen Ordner auf dem NAS vom Mac aus dupliziere, der sich auf dem NAS befindet, dauert das sehr lange - mehrere Minuten - Obwohl der Ordner nur gut 20MB groß ist.

Hat jemand einen Tipp, woran das liegen könnte?

Danke für Hinweise
Fadenschein

Entscheidend ist nicht die Größe, sondern wieviele Dateien in dem Ordner enthalten sind.
20MB können auch 20.000 Dateien mit je 1kB sein. Da dauert das Kopieren länger als bei 1 Datei mit 20MB.

Der Kopiervorgang erfolgt nicht direkt auf der NAS.
Vermutlich wird der Finder eine Datei in Häppchen lesen und an den Zielort schreiben. Dabei werden SMB/TCP-Pakete verschickt, bestätigt, Prüfsummen verifiziert. Für jede Datei 2 Mal, einmal beim Lesen und dann beim Schreiben. Bei sehr vielen kleinen Dateien ist dabei der Protokoll-Overhead schnell größer als die Datenmenge.

Bemühe doch mal in der DSM-Oberfläche in Dateibrowser, um die Dateien zu kopieren - das erfolgt dann auf der NAS und sollte deutlich schneller sein. Alternativ auch per SSH auf der NAS, aber üblicherweise wird man SSH auf einer NAS nicht aktivieren wollen.

Alles das was die über mir gesagt haben !

Verstehe und danke für die Hinweise.

Ich hatte gehofft, dass der Finder den Duplizieren Befehl an den NAS weitergibt und dann vor Ort dupliziert wird. Wenn der Ordner und sein Bestandteile in kleinen Häppchen zwischen Mac und NAS hin und herwandern müssen, ist es verständlich, dass das länger dauert.

ich habe mir kuerzlich die muehe gemacht und die drei in macOS verfuegbaren filesharing-protokolle gebenchmarked. einfaches kopieren von iWeb.app (~415 MB / ~17500 items) auf das NAS:

SMB 18m49s
AFP 9m47s
NFS 3m13s

@Mikeboss
War da SMB-Signing an oder aus? (nsmb.conf darf auch unter ~/Library/Preferences/ liegen)
Hatte das auch mal mit und ohne im Vergleich zu AFP mittels HeliosLanTest gemessen, und da war SMB ohne Signing flotter als AFP.

Wow - hätte nicht gedacht, dass SMB so schlecht ist.

ich habe den test gerade eben nochmals durchgefuehrt. jetzt mit deaktiviertem packet signing: 18m30s

SMB/CIFS hat, gerade bei tausenden kleinen dateien, einen grausamen protokoll-overhead.

die iWeb.app ist schon besonders fies mit rund 17'500 dateien/ordnern welche darin enthalten sind.

Windows 10 benoetigt fuer den gleichen task 15m37s

das NAS (SSD, keine HDD) laeuft mit einer asbach uralt version von openmediavault. moeglicherweise kann das gar kein packet signing.

NFS ist da halt schon erste sahne. wenn man zb einen ordner mit vielen dateien/ordnern anklickt ist das fast so schnell wie eine lokale SSD.

Es ist wie AFP auf einem UNIX ein Fremdkörper. NFS wurde von SUN für UNIX entwickelt und ist recht schnell. Probleme gibt es erst, wenn man Replikation etc. benötigt, da gibt es dann auf Linux/UNIX neuere FS die deutlich besser sind. Nur gibt es die i.d.R. nicht für macOS.

Welche wären das?

den test (kopieren der iWeb.app vom client zum NAS) habe ich auch noch mit Windows 10 via NFS (ja, Windows kann auch NFS) durchgefuehrt:

SMB 15m37s
NFS 8m57s

Es gibt von IBM ein aus dem HPC stammendes FS das hieß einmal GPFS. Die Server werden aktuell als Elastic Storage Server (ESS) vermarktet. Die wichtigsten Eigenschaften sind declustered RAID, immer zwei physische Server die einen logischen Server mit angeschlossenen SAS JBODs bilden, so dass einer der beiden Server ausfallen kann und man nur Bandbreite zu den Drives verliert. Das fängt bei 24 Drives an und skaliert pro logischen Server auf 634 Drives hoch. Dann kann man beliebig viele Server parallel benutzen und/oder Server spiegeln. Es gibt Installationen bei denen >10.000 Drives im Betrieb sind. Die Besonderheit beim IBM Produkt ist, dass der lokale Storage und das Netzwerkprotokoll von ein und demselben Produkt verwaltet wird.

Bei anderen Lösungen wie XtreemFS (mittlerweile tot und nur noch der kommerzielle Ableger lebt), BeeGFS, Lustre, GFS2, GlusterFS, ‌StorNext, … sieht das meist anders aus. Außer GFS2 hat man eigentlich immer ein lokales FS (XFS, ext4, o.ä.) und dann darauf das Netzwerkfilesystem. Die Vor- und Nachteile der jeweiligen FS sind zum Teil so unterschiedlich, dass man sich darüber individuell informieren muss.

Das größte Problem ist, dass die meisten Lösungen nur für Linux verfügbar sind, und Windows und macOS da eine Aussenseiterrolle einnehmen.

Bevor der Thread im Archiv verschwindet, bringe ich ihn nochmal hoch.

Ist das SMB-Signing mit SMB 3 überhaupt noch sinnvoll? Mit Blackmagic habe ich gerade gute Ergebnisse erzielt: 94 MB/s Write, 101 MB/s mit einer Synology Diskstation.
Mit dem Terminalbefehl
sehe ich, dass ich SMB 3.02 habe.
Bei Signing Supported steht dort TRUE.

Früher hat bei mir Signing off tatsächlich bewirkt, dass die Übertragungsrate von 25-35 MB/s auf 80-90 MB/s stieg. Aber ist es nicht so, dass SMB 3 grundsätzlich immer verschlüsselt sein muss? Also ohne Verschlüsselung kein SMB 3? Dann kann man sich Signing off doch mittlerweile sparen.

Kann ich übrigens SMB 3 erzwingen? In der Diskstation kann ich nur Mindest-SMP-Protokoll SMB 2 und Large MTU einstellen.