Geschwindigkeit bei smb Datenübertragung auf NAS (spez.: kleine Files)

[jteschner]

Mein Setup:
- MBP (Sonoma, WLAN)
- FB mit Gbit-LAN
- NAS (Raspi4b mit OMV6, SSD über USB3, Gbit-LAN)
Problem: bei der Übertragung von vielen kleinen Dateien (im kB-Bereich) über smb vom macOS zum NAS ist die Übertragungsgeschwindigkeit unterirdisch: zwischen 1-2 MB/s.
Bei großen Files (Video, Raw-Fotos, ...) finde ich sie recht normal mit ca. 70 MB/s.

Auf dem NAS in der smb.conf ist zur Optimierung mit Apple-Rechnern von mir bereits eingestellt:
[GLOBAL]
fruit:metadata = stream
fruit:nfs_aces = yes
min receivefile size = 16384
getwd cache = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes
write raw = yes
[<FÜR JEDEN SHARE>]
vfs objects = catia fruit streams_xattr

fruit:encoding = private

fruit:metadata = stream

fruit:resource = xattr

Die "write cache size" hatte ich auch noch gesetzt - allerdings ist dieser Parameter in den neueren Versionen von samba nicht mehr enthalten und sorgt für einen Fehler bei testparm.
Was kann ich sonst noch tun?
Hat noch jemand einen Tip für mich?

 

[lisanet]

da man deine smb.conf nicht vollständig sieht: stell sicher, das smb encryption ausgeschaltet ist oder auf dem default = nicht erwähnt = ausgeschaltet für data ist.

Aktiviere in omv den write cache bei den disks

Stelle sicher, dass die SSD nicht UAS nutzt = setze die quirks mit dem usb_storgae module in einer Datei in /etc/modules.d

vfs_fruit hat nichts mit Geschwindigkeit / Durchsatz zu tun

Edit:

Je nachdem welche SSD das ist, kann die auch so der Grund sein, wenn der Cache voll ist, bricht die ein. Billig-SSD neigen dazu.

Ansonsten ist dein WLAN auch eine mögliche Ursache. Ich persönlich halte auch vom WLAN einer FB rein gar nichts.

Edit 2:

Viele kleine Dateien kopieren dauert immer länger. Da spielt auch der Finder ein Rolle. Ich meine mich zu erinnern, dass der jedes File irgendwie einzeln anpackt, Größe ermittelt u dgl.

 

[jteschner]

da man deine cmb.conf nicht vollständig sieht: stell sicher, das smb encryption ausgeschaltet ist oder auf dem default = nicht erwähnt = ausgeschaltet für data ist.

da muss ich erst nachforschen wie das geht.
Meine smb.conf:

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.
#======================= Global Settings =======================
[global]
workgroup = WORKGROUP
server string = %h server
dns proxy = no
log level = 0
log file = /var/log/samba/log.%m
max log size = 1000
logging = syslog
panic action = /usr/share/samba/panic-action %d
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest account = nobody
load printers = no
disable spoolss = yes
printing = bsd
printcap name = /dev/null
unix extensions = yes
wide links = no
create mask = 0777
directory mask = 0777
use sendfile = yes
aio read size = 1
aio write size = 1
time server = no
wins support = no
disable netbios = yes
multicast dns register = no
server min protocol = SMB2_02
# Special configuration for Apple's Time Machine
fruit:aapl = yes
fruit:copyfile = yes
fruit:nfs_aces = no
# Extra options
fruit:metadata = stream

fruit:nfs_aces = yes
min receivefile size = 16384
getwd cache = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes
write raw = yes
#======================= Share Definitions =======================
[dokumente]
path = /srv/dev-disk-by-uuid-6b0ce653-2dd1-4da7-9197-115ba31a693e/dokumente/
guest ok = no
guest only = no
read only = no
browseable = yes
inherit acls = no
inherit permissions = yes
ea support = yes
store dos attributes = yes
vfs objects =
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = yes
valid users =
invalid users =
read list =
write list =
vfs objects = catia fruit streams_xattr
fruit:encoding = private
fruit:metadata = stream
fruit:resource = xattr

Aktiviere in omv den write back cache bei den disks

dito

Stelle sicher, dass die SSD nicht UAS nutzt = setze die quirks mit dem usb_storgae module in einer Datei in /etc/modules.d

Ist bereits - allerdings zZt noch über /boot/cmdline.txt - über /etc/modules.d mache ich es wenn ich sicher bin, dass UAS deaktiviert bleiben soll

vfs_fruit hat nichts mit Geschwindigkeit / Durchsatz zu tun

Ich weiß. Ich habe es nur der Vollständigkeit hier mit drin, um alles zu zeigen was ich geändert habe.

 

[lisanet]

... mehr geht nicht. Mir ist nichts weiter bekannt.

Was für SSD sind das?

 

[jteschner]

Die neue ist eine Fanxiang 2TB und die alte eine Samsung 840 evo 250GB
Von der Geschwindigkeit beide gleich

 

[lisanet]

Fanxiang 2TB

... deren Ruf ist nicht so gut. Kann ich aber persönlich nicht beurteilen.

 

[jteschner]

... deren Ruf ist nicht so gut. Kann ich aber persönlich nicht beurteilen.

ich hatte vorher mal ein bischen nachgeforscht und hatte eigentlich viel positives gelesen.
Daneben auch gedacht: am NAS muss es ja kein Speed-Monster sein.

Gerade noch einen Test im Vergleich zu meiner Synology gemacht (Ordner mit vielen kleinen Dateien kopiert, MBP -> Syno/Raspi)
Beides auf gleichem Niveau. In der Synology sind 2x4TB Seagate Ironwolf

Ich befürchte, dass es gar nicht an der smb-Konfig liegt (oder SSD/Festplatten), sondern eher an der Routerkonfig.
Kann das sein?

 

[lisanet]

Ich befürchte, dass es gar nicht an der smb-Konfig liegt (oder SSD/Festplatten), sondern eher an der Routerkonfig.
Kann das sein?

Was soll ein Router damit zu tun haben? Ich wüsste da nichts.

Es ist nun mal so: viele kleine Dateien brauchen lange. Es wird wie erwähnt auch mit an Finder liegen. Teste mal das Kopieren vieler kleiner Dateien mit rsync. So hast du einen Vergleich unterschiedlicher Clients.

 

[jteschner]

Was soll ein Router damit zu tun haben? Ich wüsste da nichts.

Ich auch nicht - da fehlt mir einfach das Wissen :-/ War nur so ein verzweifelter Schuss ins Blaue

Es ist nun mal so: viele kleine Dateien brauchen lange. Es wird wie erwähnt auch mit an Finder liegen. Teste mal das Kopieren vieler kleiner Dateien mit rsync. So hast du einen Vergleich unterschiedlicher Clients.

Das mache ich mal morgen mal mit kleinen Dateien - gute Idee. Aber gleich muss ich erstmal Fussball schauen
Ich weiß jedoch schon bereits, dass die Übertragung Raspi-->Raspi und Syno->Raspi erheblich schneller geht ...

Insgesamt finde ich das nur nervig, wenn man bei einem "Neuaufbau" so viel kopieren muss ud das dann gefühlt Stunden dauert.
Wenn das erledigt ist, dann sind da ja nicht mehr so viele Dateien zu kopieren/sichern. Dann geht das Ruck-Zuck.
Zum syncen zwischen MBP und NAS nehme ich zZt Forklift4 -- da dauert zB der Abgleich meines Foto-Ordners mit knapp 13000 Fotos nur ein paar Sekunden ... und wenn dann noch 20-50 kopiert werden müssen geht es auch schnell

Oh - Anpfiff

 

[MrChad]

Um viele, viele kleine Dateien per SMB von einer Seite auf die andere zu übertragen, hat es sich hier sehr bewährt, den kompletten Ordnerbaum an der Quelle in ein ZIP zu werfen, als ganzes auf die andere Seite zu schieben und am Ziel wieder auszupacken.

Die exakte Prozedur kann zwischen den Systemen etwas variieren, bleibt aber sehr ähnlich. Die Zeitersparnis rechtfertigt die Mühe allemal.

 

[jteschner]

Um viele, viele kleine Dateien per SMB von einer Seite auf die andere zu übertragen, hat es sich hier sehr bewährt, den kompletten Ordnerbaum an der Quelle in ein ZIP zu werfen, als ganzes auf die andere Seite zu schieben und am Ziel wieder auszupacken.

Die exakte Prozedur kann zwischen den Systemen etwas variieren, bleibt aber sehr ähnlich. Die Zeitersparnis rechtfertigt die Mühe allemal.

Witzig, genau das gleiche hatte ich mir auch überlegt und wollte es heute mal ausprobieren
Aber besten Dank für den Tip!

Ergänzung: und sogleich ausprobiert! Ergebnis: Perfekt!

 

[jteschner]

Witzig, genau das gleiche hatte ich mir auch überlegt und wollte es heute mal ausprobieren
Aber besten Dank für den Tip!

Ergänzung: und sogleich ausprobiert! Ergebnis: Perfekt!

Hmmm .... doch nicht perfekt ... ich bin zu blöd
1. auf MBP im Finder einen Ordner gezippt
2. Archiv per Drag'nDrop auf NAS übertragen
3. dort im Terminal: unzip Archiv
4.. Alles uncompressed und die Ordner/Dateien vorhanden
5. Im Finder sieht alles gut aus

Dann wollte ich per Finder alles wieder löschen: geht nicht. Fehler: Rechte!

Auf NAS nachgeschaut:: die Ordner haben rwx r-s r-x. -- die Dateien 644
Kam mir komisch vor. Gerade das 's' bei den Ordnern
Also Ordnerrechte auf 755 und Dateienrechte auf 666 geändert --> ging. Das 's' war weg.

Finder: löschen geht immer noch nicht. Ich bin nun etwas ratlos ...

Ergänzung: kann es was mit ACL zu tun haben? Allerdings habe die "ACL Vererbung" bei den Shares abgeschaltet ...

 

[MrChad]

Zu den Implementationsdetails deiner Linux-NAS kann ich nicht viel sagen.
Neulich habe ich gelernt, dass auf den Systemen hinter den einfachen POSIX-Permissions noch ACLs hängen. Das macht es granulärer, aber auch komplizierter.

 

[jteschner]

Danke. macOS macht da echt seltsame Dinge. Ich hatte die Tage schon mal Probleme mit Musik - da hatte ich der Musik.app gesagt, sie solle die Musik-Dateien vom NAS nehmen und dort auch verwalten. Großer Fehler! Dann verschwand plötzlich meine gesamte Musik-Bibliothek aus Plex auf dem NAS.
Was hatte Musik.app getan? Alle Rechte meiner Musik-Dateien auf dem NAS auf 600 gesetzt und damit hatte Plex keinen Zugriff mehr.

Vielleicht kann @lisanet noch was zu dem Problem sagen

 

[MrChad]

Warnung: OT-rant folgt.
____________

Was hab ich hier schon gelernt:
Der typische Mac-User hat eine tief-verwurzelte Abscheu gegen das Wort Terminal.

Das hält mich immer davon ab, mal ne Anleitung zum Thema Freigaben/Rechte aufzuschreiben. Und da geht es eben nicht ohne.
Ich denk dann immer: Am Ende implementieren sie doch wieder nur "weg mit Security - alle dürfen alles" und dann kann ich's auch lassen.

 

[jteschner]

Warnung: OT-rant folgt.
____________

Was hab ich hier schon gelernt:
Der typische Mac-User hat eine tief-verwurzelte Abscheu gegen das Wort Terminal.

Das hält mich immer davon ab, mal ne Anleitung zum Thema Freigaben/Rechte aufzuschreiben. Und da geht es eben nicht ohne.
Ich denk dann immer: Am Ende implementieren sie doch wieder nur "weg mit Security - alle dürfen alles" und dann kann ich's auch lassen.

Stimmt schon was du sagst - aber:
Why the hell kann ich das nicht wieder löschen, was ich selbst angelegt habe? (Wahrscheinlich weil ich auf Linux das zip entpackt habe und nicht auf dem Mac - denn das zip konnte ich über den Finder löschen)

Btw: ich mag das Terminal - auch wenn ich (noch) nicht alle Feinheiten kenne

 

[MrChad]

Why the hell kann ich das nicht wieder löschen

Vermutlich eine ACL in der Art von "group:everyone deny delete" oder ähnlich. Sieht man mit ls -le :

$ ls -led mrchad
drwxr-x---+ 20 mrchad  staff  640 Nov  8 14:10 mrchad
 0: group:everyone deny delete

Auf Linux eher: getfacl

 

[lisanet]

Vielleicht kann @lisanet noch was zu dem Problem sagen

.... ich wollte eigentlich hier nie über solche Dinge zu Samba schreiben, da das schnell recht komplex wird und uach ich nicht alle Aus- und Wechselwirkungen aller smb.conf Optionen kenne.

Natürlich spielen immer auch Rechte / ACL eine Rolle. Warum der Ordner dann nicht löschbar ist bzw. so erzeugt wird, kann ich adhoc nicht sagen.

Die einfachste Lösung ist:

Dateien zippen -> aufs NAS kopieren -> per ssh auf dem NAS einloggen und zum Ordner gehen -> auf der Kommandozeile dort: "unzip Archiv.zip" -> Fertig

Zum Thema Samba

Grundsätzlich liegt das Problem hier daran, dass macOS mit resource Forks und erweiterten Attributen arbeitet. EA sind eigentlich kein Problem, da viele Dateisystem das unterstützen, aber halt nicht alle. Daher werden dann auf "fremden" Dateisystemen die berühmten "AppleDouble" files angelegt, jene die mit "._" beginnen und alte mp3-Player, TV und sonst was durcheinander bringen.

Auch Samba hat für diese ._ files diverse Optionen. Und da geht es dann los mit den Wechselwirkungen

Bitte lest euch dazu die Doku zu vfs_fruit durch -> https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html

vfs_fruit hat u.a. die Optionen fruit:resource und fruit:veto_appledouble

setzt man resource auf file, dann legt Samba diese ._ Dateien an. Damit man diese nicht sieht, sollte veto_appledouble auf yes stehen. Das aber bricht die Kompatibilität mit dem macOS zip-client -> siehe Doku zu vfs_fruit

will man die Kompatibiltät mit dem macOS zip-client des Finders muss man also die ._ anlegen lassen, die dann andere clients / Programme eventuell wieder verwirren (sh. oben)

setzt man resource auf xattr, da die üblichen NAS-Dateisysteme wie ext4, btrfs ja EA können, werden die ._ files nicht angelegt. veto_appledouble hat dann gar keinen Effekt -> sh Doku

Da aber der macOS-zip-client im Finder ._ Dateien intern benötigt und offensichtlich Samba mit der option xattr das Anlegen verhindert, klappt das Entpacken eines zip vom Finder aus nicht.

Ergo: einen Tod muss man sterben, oder das Entpacken auf dem NAS direkt via Kommandozeile machen.

Das Rechte-Thema kommt dann mit möglichen Wechselwirkungen hinzu (keine Erlklärung hier von mir, nur die options)

Beteilligt sind:

- Einstellungen in omv (schreib lese Rechte der User: @jteschner deine smb.conf sagt, dass du da ncihts gemacht hast. Hole das nach)
- inherit acls
- inherit permissons
- create mask
- force create mode
- directory mask
- force directory mode
- fruit:nfs_aces

Auch da gibt es einge "ungute" Wechselwirkungen, besonders mit fruit:nfs_aces

Edit:

ich habe vergessen was zu erwähnen. Bei die "Lösung" oben muss anschließend noch der "__MACOSX" Ordner gelöscht werden

 

[jteschner]

.... ich wollte eigentlich hier nie über solche Dinge zu Samba schreiben, da das schnell recht komplex wird und uach ich nicht alle Aus- und Wechselwirkungen aller smb.conf Optionen kenne.

Das kann ich nun sehr gut verstehen!

Natürlich spielen immer auch Rechte / ACL eine Rolle. Warum der Ordner dann nicht löschbar ist bzw. so erzeugt wird, kann ich adhoc nicht sagen.

Die einfachste Lösung ist:

Dateien zippen -> aufs NAS kopieren -> per ssh auf dem NAS einloggen und zum Ordner gehen -> auf der Kommandozeile dort: "unzip Archiv.zip" -> Fertig

Ja, so habe ich das auch gemacht. Einmal mit ACLs vererben in Samba an und einmal mit aus
Das unzippen ist gar kein Thema und klappt.
Nur mittels Finder lässt sich das Entpackte (also Ordner, Unterordner und Dateien) in keinem Fall löschen. Das zip jedoch schon -- was mich nicht wundert, da ich es ja mit dem Finder auch auf das NAS gelegt habe.

Zum Thema Samba

...

Beteilligt sind:

- Einstellungen in omv (schreib lese Rechte der User: @jteschner deine smb.conf sagt, dass du da ncihts gemacht hast. Hole das nach)
- inherit acls
- inherit permissons
- create mask
- force create mode
- directory mask
- force directory mode
- fruit:nfs_aces

Auch da gibt es einge "ungute" Wechselwirkungen, besonders mit fruit:nfs_aces

Jetzt bin ich (wieder mal) verwirrt, sorry.
Sie sind doch alle lt. smb.conf s.o. für den share "dokumente" gesetzt (außer inherit acls, dass hatte ich gerade nochmal gemacht).
Hier nochmal testparm:

# Global parameters
[global]
    disable netbios = Yes
    disable spoolss = Yes
    dns proxy = No
    load printers = No
    log file = /var/log/samba/log.%m
    logging = syslog
    max log size = 1000
    min receivefile size = 16384
    multicast dns register = No
    pam password change = Yes
    panic action = /usr/share/samba/panic-action %d
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    passwd program = /usr/bin/passwd %u
    printcap name = /dev/null
    server string = %h server
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    fruit:metadata = stream

    fruit:nfs_aces = yes
    fruit:copyfile = yes
    fruit:aapl = yes
    idmap config * : backend = tdb
    create mask = 0777
    directory mask = 0777
    printing = bsd
    use sendfile = Yes


[dokumente]
    create mask = 0664
    directory mask = 0775
    force create mode = 0664
    force directory mode = 0775
    hide special files = Yes
    inherit acls = Yes
    inherit permissions = Yes
    path = /srv/dev-disk-by-uuid-6b0ce653-2dd1-4da7-9197-115ba31a693e/dokumente/
    read only = No
    vfs objects = catia fruit streams_xattr
    fruit:resource = xattr
    fruit:metadata = stream
    fruit:encoding = private

Das hatten wir doch schon mal besprochen und ich habe das so übernommen - Teile in Global und Teile für jeden Share
Oder stehe ich mal wieder auf dem Schlauch?

 

[jteschner]

Hätte ich das bloß nicht mit dem zippen getestet ... ich bereue zutiefst

Ergänzung: wenn ich normal den Ordner mit den kleinen Dateien über den Finder zum NAS kopiere kann ich ihn auch wieder löschen - alles langsam aber es funktioniert
Nur das mit dem zip geht nicht - und ich glaube damit kann ich leben - wenn auch immer noch nicht verstehen (es aber gern würde )