Zunächst einmal ist diese Frage nicht wirklich ein Problem, das ich habe, sondern eher ein"warum ist das so". Ich versuche, nach mehreren Jahren in der Windows-Welt zu Linux zurückzukehren, aber ich habe so viel verloren... Also, auf das Lernen von Neuem. :)
Ich habe eine Windows 10 x64-Maschine, die als Dateiserver in meinem Netzwerk fungiert. Ich greife von Ubuntu Mate 16.04 auf die Freigaben zu. Der Hauptdateibrowser ist Caja.
Und hier ist das Gute daran: Wenn ich die Netzwerkfreigaben in meinem Netzwerk durchsuche und beginne, eine Datei zu kopieren, liegt die maximale Geschwindigkeit bei etwa 600 Mbit. Aber wenn ich die Freigabe dauerhaft in Fstab mit CIFS mounte (gemäßhttps://help.ubuntu.com/community/MountWindowsSharesPermanently) Ich kann meine volle Verbindungsgeschwindigkeit (1 Gbit) nutzen. Ich kann die volle Verbindungsgeschwindigkeit auch nutzen, wenn ich smbclient über das Terminal verwende.
Kann mir jemand erklären, warum das bei Caja (und, soweit ich weiß, auch bei Nautilus) der Fall ist, und mir vielleicht ein paar Links geben, wo ich mehr darüber lesen kann? Sind CIFS und SMB nicht im Grunde dasselbe?
Danke!
Aktualisieren:Ich verwende eine Intel I217-V-Netzwerkkarte (Rev. 04).
Antwort1
SMB ist ein Server Message Block, der von IBM entwickelt wurde, um Dateien über ein LAN-Netzwerk zu schreiben. CIFS ist ein Common Internet File System. CIFS ist eine spezielle Implementierung von SMB, die von Microsoft durchgeführt wurde.
1.) Die CIFS-Implementierung von SMB wird heutzutage kaum noch verwendet. Die meisten modernen Speichersysteme verwenden kein CIFS mehr, sondern SMB 2 oder SMB 3. In der Windows-Welt ist SMB 2 seit Windows Vista (2006) Standard und SMB 3 ist Teil von Windows 8 und Windows Server 2012.
2.) SMB 2 und SMB 3 sind massive Upgrades gegenüber der CIFS-Implementierung.
Jetzt etwas, das Sie im Hinterkopf behalten sollten (TCP-Fenstergröße * 8 Bit/RTT in Millisekunden) = Maximaler TCP-Durchsatz in bps. Auch wenn Sie ein Gigabit-Netzwerk haben, wird ein einzelner TCP-Fluss diese Höhe wahrscheinlich nicht erreichen können.
Nun zur Optimierung der SMB-Konfiguration:
[global]
SEHEN:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532
strict allocate = Yes
SEHEN:https://lists.samba.org/archive/samba-technical/2014-July/101304.html
allocation roundup size = 4096
Erlaubt das Lesen von 65535 Bytes in einem Paket
Rohdaten lesen = Ja
Durch die Serversignatur wird das Ganze verlangsamt.
server signing = No
Unterstützt RAW-Schreiben.
write raw = Yes
„strict locking = auto“ ODER „strict locking = no“ ist akzeptabel.
strict locking = No
Socket-Optionen = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072
„min. Größe der Empfangsdatei“ wird direkt an den Kernel übergeben, recvfile/splice SYSTEM CALL.
min receivefile size = 16384
Verwenden Sie einen effizienteren Systemaufruf sendfile()
use sendfile = Yes
Samba muss mit asynchroner Dateiunterstützung und E/A-Unterstützung ausgestattet sein.
aio read size = 16384
aio write size = 16384
Auch in meinem Fall musste ich die Reihenfolge der Namenssuche in nsswitch.conf ändern. Es stellte sich heraus, dass diese Konfiguration eine Zeile wie diese enthielt.
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
Das Problem wurde einfach dadurch behoben, dass der Hosts-Zeile ein „wins“ hinzugefügt wurde.
hosts: files wins mdns4_minimal [NOTFOUND=return] dns mdns4