Pourquoi le partage monté sur CIFS est-il plus rapide que SMB?
Pour commencer, cette question n’est pas vraiment un problème que j’ai mais plutôt un "pourquoi est-ce comme ça" . J'essaie de revenir à Linux après plusieurs années dans le monde Windows, mais j'ai tellement perdu ... Alors, revenons à l'apprentissage. :)
J'ai une machine Windows 10 x64 faisant office de serveur de fichiers sur mon réseau. J'accède aux partages d'Ubuntu Mate 16.04. Le navigateur de fichiers principal est Caja.
Voici la bonne partie: Lorsque je navigue sur les partages réseau de mon réseau et commence à copier un fichier, la vitesse maximale est d'environ 600 Mbits/s. Mais lorsque je monte le partage de manière permanente dans Fstab avec CIFS (selon https://help.ubuntu.com/community/MountWindowsSharesPermanently ), je peux utiliser ma vitesse de liaison totale (1 Gbit). Je peux également utiliser la vitesse de liaison maximale lorsque smbclient via Terminal est utilisé.
Quelqu'un peut-il m'expliquer pourquoi c'est le cas de Caja (et de Nautilus d'après ce que je peux dire) et peut-être me donner des liens où je peux en lire davantage? CIFS et SMB ne sont-ils pas fondamentalement la même chose?
Merci!
Mise à jour: J'utilise une carte réseau Intel I217-V (rev 04).
SMB est un bloc de messages de serveur qui a été inventé par IBM pour écrire des fichiers sur un réseau LAN. CIFS est un système de fichiers Internet commun. CIFS est une implémentation particulière de SMB effectuée par Microsoft.
1.) L'implémentation CIFS de SMB est rarement utilisée de nos jours. La plupart des systèmes de stockage modernes n'utilisent plus CIFS, mais bien SMB 2 ou SMB 3. Dans le monde Windows, SMB 2 était la norme depuis Windows Vista. (2006) et SMB 3 fait partie de Windows 8 et Windows Server 2012.
2.) SMB 2 et SMB 3 sont des mises à niveau massives par rapport à la mise en œuvre de CIFS.
Maintenant, gardez à l’esprit (taille de la fenêtre TCP * 8bits/RTT en millisecondes) = débit maximal TCP en bps. Même si vous avez un réseau Gigabit, un seul flux TCP ne pourra probablement pas atteindre ce niveau.
Maintenant, optimisons SMB config:
[global]
VOIR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532
strict allocate = Yes
VOIR: https://lists.samba.org/archive/samba-technical/2014-July/101304.html
allocation roundup size = 4096
Autoriser la lecture de 65 535 octets dans un paquet
read raw = Oui
La signature du serveur ralentit les choses.
server signing = No
Supporte l'écriture RAW.
write raw = Yes
"verrouillage strict = auto" OR "verrouillage strict = non" est acceptable.
strict locking = No
options de socket = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF = 131072 SO_SNDBUF = 131072
"min receivefile size" sera passé directement au noyau, recvfile/splice SYSTEM CALL.
min receivefile size = 16384
Utiliser un appel système sendfile () plus efficace
use sendfile = Yes
Samba musty doit être construit avec le support de fichiers asynchrone
aio read size = 16384
aio write size = 16384
De plus, dans mon cas, je devais changer l'ordre des recherches de noms dans nsswitch.conf. Il s'avère que cette configuration contenait une ligne comme celle-ci.
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
Ajouter simplement un "wins" à la ligne hosts a résolu le problème.
hosts: files wins mdns4_minimal [NOTFOUND=return] dns mdns4