Copies lentes vers un NAS : les réglages SMB qui comptent vraiment

Ce qui rend vraiment les copies SMB lentes

SMB (Server Message Block) n’est pas une seule chose. C’est une famille de protocoles avec des versions, une négociation de dialecte, une intégrité optionnelle, un chiffrement optionnel, le multichannel optionnel, et beaucoup de comportements client « utiles ». La vitesse de copie est la propriété émergente de :

• Latence du stockage (surtout les écritures aléatoires petites pour « beaucoup de petits fichiers »).
• Bande passante réseau (évident), plus la perte, les retransmissions, et le bufferbloat (moins évident).
• Cycles CPU côté client et serveur pour la signature/le chiffrement et pour tout pilote antivirus/filtrage.
• Contrôle de flux SMB : crédits, I/O en attente, et combien de requêtes peuvent être en vol.
• Churn de métadonnées : créations, fermetures, lectures d’attributs, vérifications ACL, durable handles, énumération de répertoires.
• Comportement de l’application : copie via l’Explorateur vs robocopy vs une application faisant des copies de type synchronisation.

Deux travaux de copie « de même taille » peuvent se comporter comme des planètes différentes :

• Un ISO de 50 Go est majoritairement I/O séquentiel. Il veut de la bande passante et de grands tampons.
• Deux millions de fichiers de 16 Ko c’est des métadonnées et de l’I/O aléatoire. Il faut faible latence, opérations de répertoire rapides, et des politiques antivirus sensées.

L’optimisation des performances SMB, bien faite, consiste surtout à ne pas lutter contre votre goulot. Mal faite, c’est du culte cargo : MTU plus grand, plus de threads, plus de cache, plus « d’optimisation ». C’est comme ça qu’on finit avec un NAS « optimisé » transformé en radiator coûteux.

Blague #1 : L’optimisation SMB, c’est comme assaisonner une soupe — ajoutez le sel lentement, parce que « vider tout le saloir » est la façon de se faire réveiller à 2h du matin.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Si vous ne retenez qu’une chose, retenez ceci : séparez le disque, le réseau et les fonctionnalités SMB. Ne commencez pas par changer des paramètres. Commencez par prouver où se situe le plafond.

Premier : classer la charge

• Fichier unique et volumineux ? Attendez-vous au débit maximal si les disques sont corrects et si SMB n’utilise pas des fonctions de sécurité coûteuses.
• Beaucoup de petits fichiers ? Attendez-vous à être plus lent. Puis demandez : « Est-ce anormalement plus lent qu’il y a un mois ? »
• Lecture vs écriture ? Les écritures sont souvent plus lentes à cause du comportement synchrone, des snapshots, de la parité RAID, ou de l’absence de SLOG (pour ZFS).

Second : prouver la capacité brute du réseau (sans SMB)

• Utilisez iperf3 entre le client et le NAS (ou le NAS et une machine de test sur le même VLAN).
• Si vous n’approchez pas la bande attendue ici, SMB ne vous sauvera pas.

Troisième : prouver la capacité de stockage du NAS (sans SMB)

• Mesurez le débit disque et la latence sur le NAS lui‑même (fio est idéal ; des outils basiques conviennent aussi).
• Si le NAS est déjà à 80–100% CPU, vos réglages SMB sont cosmétiques.

Quatrième : valider le dialecte SMB et les fonctionnalités coûteuses

• Vérifiez la version SMB, l’état du signing, l’état du chiffrement, le multichannel, RSS.
• Recherchez antivirus, DLP, filtrage de fichiers, ou surcharge de quotas.

Cinquième : capturez un test « propre » et une copie « réelle »

• Un gros fichier généré sur le client (pour qu’il ne soit pas limité par la lecture disque du client).
• Un dossier représentatif du « problème ».
• Comparez les comportements. Si seul le cas des petits fichiers est mauvais, tunez pour les métadonnées/la latence, pas pour la bande passante.

Faits et historique qui expliquent les bizarreries actuelles

Les problèmes de performance SMB ressemblent souvent à des mystères jusqu’à ce que vous vous rappeliez d’où vient SMB et ce que le protocole essaie de garantir.

1. SMB est né dans les années 1980 (racines IBM, puis adopté et étendu par Microsoft). Beaucoup de comportements « bavards » sont des bagages historiques.
2. SMB1 a été conçu pour des LAN avec d’autres hypothèses ; ses inefficacités (et problèmes de sécurité) sont la raison pour laquelle les environnements modernes doivent traiter SMB1 comme « non ».
3. SMB2 (ère Vista/Server 2008) a réduit drastiquement la bavardage et amélioré le pipelining — c’est une des raisons pour lesquelles SMB2/3 peut être beaucoup plus rapide sur des liens à latence élevée.
4. SMB3 a introduit le chiffrement et le multichannel (ère Windows 8/Server 2012). Excellentes fonctionnalités, mais elles peuvent taxer le CPU ou exposer des bizarreries de carte réseau/driver.
5. Le SMB signing existait bien avant que « zero trust » devienne une expression ; il protège l’intégrité, mais a un coût mesurable en performance — surtout sur des CPU faibles ou quand les offloads ne sont pas disponibles.
6. Le comportement de copie de l’Explorateur a changé selon les versions de Windows (tailles des tampons, retrys, UI « conviviale »). Robocopy est souvent plus prévisible pour les tests.
7. Les opportunistic locks (oplocks) et leasing ont été introduits pour réduire les allers-retours réseau en cachant — jusqu’à ce qu’une app ou un scanner invalide les caches et force des ruptures constantes.
8. Les crédits SMB sont le contrôle de flux ; sur des tuyaux larges avec RTT élevé (ou serveurs occupés), un comportement de crédit inadapté peut brider les I/O en vol.
9. Les jumbo frames sont devenues à la mode avec le 10GbE, mais SMB ne les exige pas magiquement ; les jumbo réduisent surtout la charge CPU et les interruptions quand tout est correctement configuré de bout en bout.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement quand quelqu’un dit « SMB est lent ». Chacune inclut : la commande, ce qui « est bon », et la décision que vous prenez.

Task 1: Confirm SMB dialect, encryption, signing (Windows client)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Encrypted,Signed,NumOpens | Format-Table -Auto"
ServerName ShareName Dialect Encrypted Signed NumOpens
--------- --------- ------- --------- ------ --------
nas01     data      3.1.1   False     True   12

Ce que cela signifie : Vous êtes en SMB 3.1.1, le chiffrement est désactivé, le signing est activé. Ce « Signed=True » peut être imposé par une politique.

Décision : Si les performances sont faibles et que le CPU est élevé, vérifiez si le signing est requis. Si la politique le requiert, arrêtez de discuter et optimisez ailleurs (RSS, multichannel, CPU, pilotes NIC).

Task 2: Measure raw network throughput with iperf3

cr0x@server:~$ iperf3 -c nas01 -P 4 -t 10
Connecting to host nas01, port 5201
[SUM]   0.00-10.00  sec  4.65 GBytes  3.99 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.64 GBytes  3.99 Gbits/sec                  receiver

Ce que cela signifie : Votre chemin réseau peut réellement atteindre ~4 Gbps avec quatre flux. Parfait.

Décision : Si iperf3 est bas, corrigez la vitesse/duplex NIC, le câblage, la configuration du switch, le VLAN, le QoS, ou le Wi‑Fi avant de toucher SMB.

Task 3: Check NIC link speed and errors (Linux NAS)

cr0x@server:~$ sudo ethtool eno1
Settings for eno1:
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
Link detected: yes

Ce que cela signifie : Le lien est actif à 10GbE full duplex. C’est la ligne de départ.

Décision : Si ça affiche 1000Mb/s alors que vous attendez 10GbE, arrêtez. Trouvez le câble défectueux, le mauvais SFP, ou la configuration du port de switch.

Task 4: Check interface counters for drops/retransmit hints (Linux)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0      12       0    1234
    TX:  bytes packets errors dropped carrier collsns
    123456789  2345678      0       8       0       0

Ce que cela signifie : Des drops non nuls. Quelques-uns peuvent être du bruit ; une croissance persistante durant les tests est un signal d’alarme.

Décision : Si les drops augmentent pendant la copie, vous regardez la congestion, des problèmes de tampon, ou des soucis d’offload/driver. Corrigez cela avant de tuner Samba.

Task 5: Confirm MTU end-to-end (Linux)

cr0x@server:~$ ping -M do -s 8972 nas01 -c 2
PING nas01 (10.20.0.10) 8972(9000) bytes of data.
8972 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=0.321 ms
8972 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=0.299 ms

--- nas01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Ce que cela signifie : Les jumbo frames (MTU 9000) fonctionnent probablement sur ce chemin.

Décision : Si cela échoue, n’activez pas les jumbo frames « parce que c’est plus rapide ». Les jumbo partiels sont pires que pas de jumbo ; ils provoquent fragmentation ou blackholes selon l’équipement.

Task 6: Check SMB multichannel state (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Format-Table -Auto"
Server Name Client IP   Server IP   Client Interface Index Server Interface Index RSS Capable RDMA Capable
----------- ---------   ---------   ---------------------- --------------------- ----------- ------------
nas01       10.20.0.21  10.20.0.10  14                     12                    True        False

Ce que cela signifie : Le multichannel existe et RSS est capable. S’il y avait plusieurs interfaces, vous verriez plusieurs lignes.

Décision : Si le multichannel est attendu mais absent, vérifiez le support serveur SMB (version/config Samba), les paramètres RSS de la NIC, ou s’il n’y a qu’un seul chemin viable.

Task 7: Check client RSS / offload posture (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select-Object Name,Enabled,NumberOfReceiveQueues,Profile | Format-Table -Auto"
Name        Enabled NumberOfReceiveQueues Profile
----        ------- --------------------- -------
Ethernet0   True    8                     ClosestProcessor

Ce que cela signifie : RSS est activé. Bien : SMB peut répartir le traitement.

Décision : Si RSS est désactivé sur une NIC 10GbE client/serveur, vous bottlenez souvent un seul cœur CPU. Corrigez RSS avant de toucher Samba.

Task 8: Verify server-side CPU saturation (Linux NAS)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.6.0 (nas01)  02/05/2026  _x86_64_  (16 CPU)

03:11:01 PM  CPU   %usr %nice %sys %iowait %irq %soft %idle
03:11:02 PM  all   22.10  0.00  8.33   1.50 0.00  2.10 66.0
03:11:02 PM    7   91.00  0.00  6.00   0.00 0.00  0.00  3.0

Ce que cela signifie : Un cœur est à ~91% alors que le CPU global va bien. C’est un signe classique d’affinité/interrupt/RSS, ou de travail mono‑thread (crypto, file d’attente unique).

Décision : Si un cœur est saturé pendant une copie SMB, investiguez RSS, les interruptions NIC, et si la signature/le chiffrement brûlent un seul thread.

Task 9: Observe disk latency during the copy (Linux NAS)

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user %nice %system %iowait  %idle
          18.12  0.00   6.44    4.10  71.34

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
nvme0n1          2.0  450.0   64.0 51200.0  2.10  0.20   9.5
md0              0.0  820.0    0.0 52000.0 18.50  0.00  98.0

Ce que cela signifie : Le backend (md0) est près de 100% utilisé avec ~18 ms d’await. C’est votre limiteur pour les écritures.

Décision : Arrêtez le « tuning SMB » et corrigez le stockage : cache d’écriture, niveau RAID, recordsize ZFS, SLOG, nombre de disques, ou déplacez la charge sur SSD.

Task 10: Confirm Samba is actually using aio and sensible socket options (Linux NAS)

cr0x@server:~$ testparm -s | egrep -i "aio|socket|smb2 leases|server multi channel|server signing|smb encrypt"
	aio read size = 1
	aio write size = 1
	server multi channel support = yes
	server signing = mandatory
	smb encrypt = disabled
	socket options =
	smb2 leases = yes

Ce que cela signifie : AIO est activé (seuil 1 signifie pratiquement toujours), le multichannel est supporté, le signing est obligatoire.

Décision : Si le signing est obligatoire et que le CPU est votre goulot, envisagez « signing desired » (si la politique le permet) ou mettez à niveau le CPU / activez l’accélération crypto. Si le multichannel est désactivé, activez‑le seulement après avoir vérifié la stabilité NIC et switch.

Task 11: Check if SMB is falling back to SMB1 or NT1 anywhere (Linux server logs)

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "SMB1|NT1|deprecated|protocol"
Feb 05 14:22:18 nas01 smbd[2143]: protocol negotiation failed: client requested NT1

Ce que cela signifie : Un client tente d’utiliser SMB1 (NT1). Cela peut causer des performances catastrophiques et une exposition à la sécurité.

Décision : Trouvez le client, désactivez SMB1, et imposez un protocole minimum SMB2_02 ou supérieur.

Task 12: Test a controlled large-file write from a Windows client (robocopy)

cr0x@server:~$ powershell -NoProfile -Command "robocopy C:\temp \\nas01\data\perf-test bigfile.bin /np /r:0 /w:0 /mt:8"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Source : C:\temp\
    Dest : \\nas01\data\perf-test\

    Files : bigfile.bin

  Options : *.* /MT:8 /R:0 /W:0 /NP

------------------------------------------------------------------------------
               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         0         1         0         0         0
   Files :         1         1         0         0         0         0
   Bytes : 50.000 g  50.000 g         0         0         0         0
   Times :   0:02:10   0:02:10                       0:00:00   0:00:00
   Speed :           410.123 MegaBytes/min
   Speed :            6.835 MegaBytes/sec

Ce que cela signifie : 6,8 Mo/s vers un NAS est catastrophiquement bas pour un flux unique. Maintenant vous savez que ce n’est pas « petits fichiers ». Quelque chose limite fondamentalement les écritures.

Décision : Corrélez cela avec iostat (stockage), iperf3 (réseau), et CPU. Ne chassez pas les oplocks ; chassez le limiteur.

Task 13: Confirm Windows isn’t writing with pathological buffering behavior (Performance counters)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\SMB Client Shares(*)\Avg. Write Queue Length' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue"
Path                                                     CookedValue
\\SMB Client Shares(\\nas01\data)\Avg. Write Queue Length 15

Ce que cela signifie : Une longue file d’écriture côté client SMB suggère que le client attend des accusés de réception du serveur (le serveur est lent ou flow controlled).

Décision : Si la longueur de la file reste élevée alors que le réseau est sous‑utilisé, investiguez la latence disque serveur, les crédits SMB, ou la signature/le chiffrement côté CPU.

Task 14: Check TCP retransmits on Linux (server or client)

cr0x@server:~$ netstat -s | egrep -i "retransm|segments retransm"
    184 segments retransmitted

Ce que cela signifie : Des retransmissions existent. Le nombre absolu n’est pas le point ; la tendance pendant les tests l’est.

Décision : Si les retransmissions montent vite pendant les copies, corrigez les problèmes de couche 1/2/3, les offloads, ou la congestion. Le tuning SMB ne compensera pas la perte de paquets.

Task 15: Validate Samba per-share options that affect caching and durability

cr0x@server:~$ testparm -s --section=data | egrep -i "strict sync|sync always|durable handles|kernel oplocks|oplocks|vfs objects"
	strict sync = yes
	sync always = yes
	kernel oplocks = yes
	oplocks = yes
	durable handles = yes
	vfs objects = acl_xattr

Ce que cela signifie : sync always = yes force des écritures synchrones. C’est un tueur de performance sauf si vous en avez absolument besoin.

Décision : Si c’est un partage à usage général, désactivez sync always. S’il s’agit d’une base de données qui exige la sémantique sync, alors il vous faut un stockage adapté (SLOG, BBWC, etc.), pas une configuration magique.

Les réglages SMB qui comptent vraiment

La plupart des « réglages SMB » trouvés sur Internet sont soit obsolètes, placebo, soit dangereux en production. Voici ceux qui font réellement bouger l’aiguille — parce qu’ils s’alignent sur de vrais goulots.

1) Corrigez d’abord les trucs ennuyeux : vitesse/duplex, câblage et symétrie des chemins

Si votre NAS négocie 1GbE d’un côté et 10GbE de l’autre, SMB vous donnera fidèlement des performances 1GbE. Pareil si vous avez un bond LACP « utile » qui hash tout le trafic sur un lien physique parce que c’est une seule session TCP. Vous n’avez pas besoin d’un guide de tuning ; il faut arrêter de deviner.

2) SMB Multichannel : un vrai gain, mais seulement si vos NIC se comportent

SMB Multichannel peut utiliser plusieurs connexions TCP à travers des NIC (ou à travers plusieurs queues sur une NIC via RSS). Cela aide le débit et la résilience. Ça ajoute aussi de la complexité : plus de flux, plus de chances de tomber sur un driver buggy, et plus de sensibilité à l’asymétrie.

• Faites‑le quand vous avez du 10/25/40GbE et des clients Windows modernes, et que vous pouvez valider un comportement multi‑queues stable.
• Évitez le « demi‑multichannel » où le serveur le supporte mais le client a RSS désactivé (ou inversement). C’est ainsi qu’on fige un seul cœur et qu’on se demande pourquoi le lien est inactif.

3) RSS et distribution des interruptions : le capteur silencieux du débit

Si un seul cœur CPU est saturé pendant les transferts SMB, vous plafonnerez à un nombre suspectement constant (souvent quelques Gbps ou moins) tandis que le reste du système dort. RSS répartit le traitement des réceptions. La modulation d’interruption et le nombre de queues sont aussi importants.

Ce qu’il faut faire :

• Activez RSS sur les NIC Windows ; vérifiez plusieurs queues de réception.
• Sur Linux, assurez‑vous que le multiqueue est activé, et que les interruptions sont distribuées sensément.
• Mettez à jour le firmware/les drivers NIC. Oui, c’est ennuyeux. Oui, ça compte.

4) Signature et chiffrement : sachez ce que vous payez

Le signing SMB garantit l’intégrité : il empêche la falsification. Le chiffrement SMB protège la confidentialité. Ce sont de bons contrôles de sécurité, mais ils coûtent en CPU et peuvent réduire le débit.

Règles que j’applique en production :

• Si vous êtes sur un LAN de confiance et que la politique le permet : n’exigez pas le signing pour chaque partage. Mettez‑le en « desired », pas en « mandatory ».
• Si vous devez chiffrer : assurez‑vous que le CPU du NAS a AES‑NI (ou équivalent) et que vous ne confiez pas la crypto à un seul cœur.
• Ne chiffrez pas deux fois (chiffrement SMB plus VPN) à moins d’avoir budgété le CPU pour cela.

Une idée paraphrasée d’un grand nom de la fiabilité : « l’espoir n’est pas une stratégie » — souvent citée en ingénierie et opérations.

5) N’obligez pas les écritures synchrones sauf si c’est nécessaire

Des réglages comme sync always (Samba) ou des comportements « toujours synchrones » au niveau stockage peuvent transformer un NAS en machine à latence d’écriture. Cela peut être correct pour des charges transactionnelles. Pour des partages utilisateur, c’est généralement s’automutiler.

Si votre organisation dit « nous avons besoin de zéro perte de données en cas de panne électrique », achetez du matériel qui le supporte (cache avec batterie, journalisation correcte, ou conception ZFS intent log) et testez‑le. Ne collez pas « sync always » sur un pool SSD grand public et ne l’appelez pas entreprise.

6) Adaptez au type de charge : gros fichiers vs petits fichiers

Pour les gros transferts séquentiels, concentrez‑vous sur :

• Bande passante, RSS, multichannel, marge CPU, et éviter les fonctions de sécurité coûteuses quand la politique le permet.

Pour des millions de petits fichiers, concentrez‑vous sur :

• Performance des métadonnées sur le NAS (SSD pour métadonnées, RAM suffisante, opérations de répertoire rapides).
• Exclusions antivirus côté client et serveur (de manière ciblée).
• Réduire les lectures d’attributs/ACL inutiles quand c’est possible.

7) Samba AIO et sendfile : de bons choix par défaut, mais validez

L’I/O asynchrone de Samba et le sendfile zéro‑copie peuvent aider. Sur des kernels modernes, Samba fait généralement du bon boulot. Mais vous devez vérifier que votre NAS n’est pas contraint ailleurs.

• AIO aide quand il y a un bénéfice à I/O parallèle et que le système de fichiers sous‑jacent le supporte bien.
• sendfile peut réduire le CPU pour les lectures. Ça ne réparera pas des écritures lentes.

Soyez méfiant des « socket options » aléatoires collées depuis 2009. Si vous voyez quelqu’un recommander TCP_NODELAY et d’énormes tampons comme solution universelle, vous lisez du folklore.

8) Désactivez SMB1. Toujours.

Si un appareil ancien force SMB1, isolez‑le sur son propre VLAN/partage, restreignez l’accès, et planifiez son retrait. SMB1 n’est pas « rétrocompatible » ; c’est « compatible attaque ». C’est aussi lent, bavard, et désagréable en cas de latence.

Blague #2 : Si vous exécutez encore SMB1, vous ne « supportez pas le legacy » ; vous gérez une pièce de musée qui reçoit parfois du ransomware.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau NAS pour remplacer un vieux serveur de fichiers Windows. L’achat était justifié par le « débit brut » — beaucoup de disques, uplinks 10GbE, et un tableau de bord qui montrait fièrement un faible CPU au repos. Le week‑end de migration s’est bien passé. Le lundi, non.

Les utilisateurs se plaignaient que l’ouverture des dossiers projet prenait une éternité. Les copies « se bloquaient » aléatoirement. Le helpdesk a escaladé vers « problèmes réseau » parce que le ping semblait correct et que les applis web étaient rapides. Pendant ce temps, l’équipe stockage insistait que le NAS « ne faisait presque rien » parce que les graphiques de débit n’étaient pas saturés.

La mauvaise hypothèse était que débit faible signifiait système inactif. En réalité, la charge avait évolué de « gros fichiers CAO » à « milliers de petits artefacts de build » au fil des années. L’Explorateur faisait des lectures d’attributs, des vérifications ACL, et du thumb‑nailing. Sur le NAS, le RAID sous‑jacent était correct pour le débit séquentiel mais avait une latence médiocre sous churn de métadonnées, et le partage avait strict sync activé « pour la sécurité ».

Une fois que quelqu’un a tracé la latence disque (await) et pas seulement le MB/s, tout s’est éclairé. L’array passait son temps à être très utilisé pour de petites écritures et flushs. La solution n’était pas un drapeau magique SMB. Ils ont déplacé les partages riches en métadonnées vers du stockage SSD‑backed, retiré sync always des partages généraux, et ajouté une exclusion antivirus ciblée pour les répertoires de build. La vitesse de copie a bondi, et l’ouverture de dossiers a cessé d’être génératrice de tickets.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait des écritures SMB lentes vers un NAS basé sur Samba. Quelqu’un a lu un blog de tuning et a décidé que les jumbo frames « débloqueraient la performance ». Ils ont mis MTU 9000 sur le NAS, le switch cœur, et quelques serveurs. Les postes et certains switches d’accès sont restés à 1500 parce que « ça va négocier ». Ça ne l’a pas fait.

Pendant un jour, la performance était étrange : parfois fulgurante, parfois lente, parfois figée pendant des secondes. Des captures montrent des retransmissions et des motifs de fragmentation incompréhensibles pour un LAN. Le helpdesk voyait des popups « lecteur réseau déconnecté ». L’équipe stockage ne voyait pas d’erreurs disques. Tout le monde se renvoyait la balle, cercle de la vie.

Le problème racine était des jumbo partiels et une MTU de chemin incohérente. Certains flux restaient dans un domaine MTU propre ; d’autres traversaient du matériel incapable de passer du jumbo, entraînant des drops et retries. SMB, protocole fiable sur TCP, a réessayé — et le débit s’est effondré.

La correction a été brutale mais simple : revenir à MTU 1500 partout, puis réintroduire le jumbo seulement après audit de chaque saut (y compris les vSwitchs de virtualisation et les interfaces de firewall). La performance est devenue d’abord stable, puis rapide. L’« optimisation » n’a pas échoué parce que les jumbo frames sont mauvaises. Elle a échoué parce que le réseau a été traité comme une bague d’humeur.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise recevait des plaintes récurrentes : « SMB est lent » après chaque cycle de patch trimestriel. L’équipe stockage en avait assez des interventions réactives, alors ils ont mis en place une pratique peu glamour : un test de base de performance SMB reproductible, exécuté chaque semaine et stocké avec les métriques système.

Le baseline comprenait trois tests : iperf3 pour le débit, une écriture robocopy gros fichier, et une robocopy orientée petits fichiers/métadonnées. Ils enregistraient les versions de drivers NIC, le dialecte SMB, l’état signing/chiffrement, et le CPU/latence disque du NAS pendant chaque exécution.

Une semaine, le test gros fichier a chuté de moitié alors qu’iperf3 restait normal. La latence disque était correcte. Le CPU montrait un cœur qui piquait. Grâce aux baselines historiques, ils ont rapidement corrélé la régression à un nouveau driver NIC sur un sous‑ensemble de clients Windows qui désactivait RSS à cause d’un paramètre « compatibilité ». Personne ne l’aurait remarqué dans la surveillance normale parce que le CPU moyen allait bien et les graphes réseau semblaient normaux.

Ils ont rollback le driver, réactivé RSS, et la performance est revenue. La victoire n’était pas un réglage intelligent. La victoire était d’avoir une baseline et de traiter la performance SMB comme un SLO surveillé, pas comme une rumeur.

Erreurs courantes : symptôme → cause racine → correction

1) « Le réseau est rapide, mais les copies SMB sont lentes »

Symptôme : iperf3 semble bon, mais les copies de fichiers plafonnent bas.

Cause racine : surcharge CPU due à la signature/chiffrement, ou latence disque sur le NAS, ou goulot mono‑cœur dû à RSS/offload.

Correction : Vérifiez l’état du signing/chiffrement SMB, mesurez le CPU par cœur, confirmez RSS/multichannel, puis mesurez l’await disque durant la copie.

2) « Fichier unique volumineux rapide, mais dossiers avec beaucoup de petits fichiers douloureux »

Symptôme : Les ISO se copient vite ; les arbres sources rampent.

Cause racine : surcharge de métadonnées (créations/fermetures/vérifs ACL), scan antivirus, snapshots, ou opérations de répertoire lentes.

Correction : Utilisez robocopy avec et sans multithreading ; revoyez les exclusions antivirus ; mettez les partages riches en métadonnées sur SSD ; réduisez les réglages sync pathologiques.

3) « C’était rapide hier ; aujourd’hui c’est lent »

Symptôme : Régression soudaine, pas de changement topologique (soi‑disant).

Cause racine : mise à jour driver/firmware, changement de politique SMB (signature exigée), changement MTU de chemin, ou nouveau produit de sécurité inline.

Correction : Comparez les propriétés de connexion SMB et les paramètres NIC ; vérifiez les logs de changements ; validez la MTU end‑to‑end ; confirmez l’absence de nouveaux drivers de filtrage ou de mises à jour NAS.

4) « La copie SMB se fige toutes les quelques secondes »

Symptôme : Débit en rafales ; la barre de progression fait des pauses.

Cause racine : bufferbloat/congestion, pertes de paquets et retransmissions, ou comportement de flush stockage (écritures sync, tempêtes de flush).

Correction : Vérifiez les drops/retransmissions d’interface ; vérifiez le queueing/QoS du switch ; mesurez la latence disque et les paramètres de cache du NAS ; retirez le sync forcé quand ce n’est pas nécessaire.

5) « Seuls certains clients sont lents »

Symptôme : Un département se plaint ; les autres vont bien.

Cause racine : Drivers NIC différents, Wi‑Fi vs filaire, GPO de sécurité différente (signature), ou chemins différents (stack de switch différent).

Correction : Comparez les sorties de Get-SmbConnection ; lancez iperf3 depuis clients lents vs rapides ; vérifiez la vitesse du lien, RSS, et les compteurs d’erreurs.

6) « L’activation des jumbo frames a empiré les choses »

Symptôme : Blocages intermittents, retransmissions, déconnexions.

Cause racine : Configuration jumbo partielle ou équipement intermédiaire incapable de passer du jumbo.

Correction : Revenez à MTU 1500 ; prouvez le jumbo avec pings DF sur chaque saut ; puis réactivez de façon consistante ou oubliez‑le.

7) « Nous avons activé le chiffrement SMB et maintenant tout est lent »

Symptôme : Le débit chute, le CPU augmente.

Cause racine : Crypto liée au CPU, pas d’accélération matérielle, ou chemin de chiffrement mono‑threadé sur cette plateforme.

Correction : Assurez‑vous que l’accélération AES existe et est utilisée ; montez en CPU ; envisagez de chiffrer seulement les partages sensibles ; validez multichannel/RSS pour répartir la charge.

8) « Nous avons ajouté LACP, donc ça devrait être plus rapide »

Symptôme : Toujours limité proche d’une vitesse de lien unique.

Cause racine : Un flux TCP unique hash sur un membre physique ; SMB sans multichannel ne stripe pas nécessairement une copie de fichier sur plusieurs liens.

Correction : Utilisez SMB multichannel pour le parallélisme ; ou testez plusieurs flux concurrents ; réglez la politique de hashing si approprié ; ne vendez pas LACP comme une magie de débit par flux.

Listes de contrôle / plan étape par étape

Étape par étape : stabiliser d’abord, puis accélérer

1. Choisissez deux tests : un gros fichier (10–50 Go) et un dossier représentatif « petits fichiers ».
2. Lancez iperf3 pour valider la capacité brute du réseau et le comportement des retransmissions.
3. Vérifiez la vitesse du lien sur le client et le NAS, et vérifiez les compteurs pour les drops.
4. Confirmez le dialecte SMB et si le signing/le chiffrement sont activés/exigés.
5. Mesurez le CPU NAS par cœur pendant la copie ; surveillez un cœur bloqué.
6. Mesurez la latence disque NAS (await/%util) pendant la copie.
7. Si limité par le réseau : corrigez la cohérence MTU, la congestion du switch, le câblage, les drivers NIC.
8. Si limité par le CPU : activez RSS, validez multichannel, envisagez de réduire les exigences de signing/chiffrement si la politique le permet, ou augmentez le CPU.
9. Si limité par le disque : déplacez la charge vers un stockage plus rapide, ajoutez des SSD, corrigez la topologie RAID/ZFS, retirez le sync forcé pour les partages généraux.
10. Seulement maintenant : ajustez les paramètres Samba/SMB qui correspondent au goulot prouvé.
11. Retestez avec le même jeu de données et la même méthode. Conservez les résultats.
12. Opérationnalisez : créez un job de baseline hebdomadaire pour détecter les régressions avant les utilisateurs.

Checklist rapide « à faire / à éviter »

• Faire : traiter la performance SMB comme un système : client + serveur + réseau + stockage.
• Faire : mesurer la latence, pas seulement le débit.
• Faire : garder SMB1 désactivé et faire respecter SMB2+.
• Ne pas : activer les jumbo frames sauf si vous prouvez le support MTU end‑to‑end.
• Ne pas : forcer les écritures synchrones sur des partages généraux.
• Ne pas : coller des « socket options » Samba anciennes et attendre des miracles.
• Ne pas : confondre la bande agrégée LACP avec le débit d’un seul flux.

FAQ

1) Pourquoi la copie via l’Explorateur Windows semble plus lente que robocopy ?

L’Explorateur est optimisé pour l’expérience utilisateur : rapport de progression, aperçus, et parfois comportement de buffering différent. Robocopy est plus déterministe pour les tests et peut paralléliser avec /mt.

2) Dois‑je activer SMB Multichannel sur Samba ?

Si vos clients sont Windows modernes et que votre pile NIC/driver est stable, oui — le multichannel peut augmenter le débit et réduire le goulot mono‑cœur. Validez avec Get-SmbMultichannelConnection et surveillez le CPU/les interruptions.

3) Les jumbo frames aident‑elles la performance SMB ?

Parfois. Elles réduisent le surcoût par paquet et peuvent améliorer l’efficacité CPU sur du 10GbE+. Mais uniquement si chaque saut supporte la MTU. Le jumbo partiel est un piège de performance.

4) Pourquoi les petits fichiers se copient‑ils si lentement même sur un NAS SSD rapide ?

Les copies de petits fichiers sont dominées par les opérations de métadonnées, vérifications ACL, et opens/closes — pas le débit brut. Le scan antivirus et les snapshots amplifient la douleur. Mesurez la latence des opérations de répertoire et le CPU serveur, pas seulement le MB/s.

5) Le SMB signing vaut‑il la perte de performance ?

Le signing protège contre la falsification et certaines classes d’attaques. S’il « vaut » la peine est une décision de sécurité. Opérationnellement : si vous devez signer, planifiez le CPU en conséquence et assurez‑vous que RSS/multichannel sont corrects pour ne pas saturer un cœur.

6) Dois‑je désactiver le chiffrement SMB pour accélérer ?

Seulement si la politique le permet et que le réseau est de confiance. Un meilleur premier pas est de vérifier l’accélération matérielle crypto et de chiffrer seulement les partages sensibles quand c’est possible.

7) Pourquoi la performance SMB plafonne autour de ~110 Mo/s même sur un NAS « 10GbE » ?

110 Mo/s est suspectement proche du débit d’un lien 1GbE. Vérifiez la négociation de vitesse, les câbles défectueux, un switch 1GbE sur le chemin, ou une station d’accueil client seulement gigabit.

8) Quel est le moyen le plus simple de savoir si les disques du NAS sont le goulot ?

Surveillez iostat -x pendant la copie. Si %util est proche de 100% et que await grimpe, les disques vous limitent. Si les disques semblent corrects mais que le CPU ou les compteurs réseau montent, regardez là‑bas ensuite.

9) LACP (bonding) peut‑il doubler la vitesse de ma copie SMB ?

Pas pour un seul flux TCP dans la plupart des cas. LACP augmente la bande agrégée sur plusieurs flux. SMB Multichannel est la fonctionnalité qui peut réellement utiliser plusieurs connexions pour une session.

10) Quels réglages Samba sont le plus souvent « accidentellement nuisibles » ?

sync always et des réglages agressifs de « durability » appliqués aux mauvais partages. Aussi, le signing/chiffrement obligatoire sans plan CPU. Et des options socket aléatoires copiées depuis d’anciens posts de tuning.

Conclusion : étapes pratiques suivantes

Si les copies SMB vers votre NAS sont lentes, vous n’avez pas besoin d’un sorcier. Vous avez besoin d’une boucle de mesure courte et de la discipline pour changer une chose à la fois.

1. Exécutez iperf3 et validez la vitesse du lien et les erreurs. Prouvez le réseau.
2. Exécutez un test robocopy gros fichier et surveillez le CPU NAS par cœur et la latence disque. Prouvez si vous êtes limité par le CPU ou le disque.
3. Vérifiez les fonctionnalités SMB : dialecte, signing, chiffrement, multichannel, RSS. Identifiez les options coûteuses que vous payez.
4. Corrigez le goulot racine, pas le symptôme : la latence stockage requiert des corrections stockage ; la perte de paquets requiert des corrections réseau ; les cœurs bloqués requièrent RSS/drivers.
5. Établissez une baseline pour détecter les régressions après patch, pas après que l’assistante du CFO essaie d’ouvrir « Q4 Budget FINAL v7.xlsx ».

Faites cela, et « SMB est lent » cesse d’être une plainte vague et devient un problème résolu avec justificatifs.