Ubuntu 24.04 : CIFS trop lent — options de montage qui améliorent généralement le débit (cas n°22)

Quelques faits qui comptent vraiment

Le contexte ne fait pas bouger les paquets plus vite, mais il vous empêche d’essayer les mauvais réglages. Voici quelques faits courts et concrets et des éléments historiques qui reviennent dans les vraies enquêtes :

1. SMB est plus ancien que vos trois derniers « stacks » de stockage « modernes ». Il remonte aux années 1980 ; SMB3 d’aujourd’hui appartient à la même famille, avec des couches de sécurité et de performance ajoutées au fil du temps.
2. Le client Linux CIFS n’est pas un gadget userspace FUSE. Le client Linux moderne est un module noyau (cifs.ko) avec des décennies d’ajustements, mais il hérite des sémantiques SMB (métadonnées bavardes, verrous, ACL).
3. SMB1 est mort pour des raisons de performance et de sécurité. SMB2/3 ont réduit la bavardise et amélioré le pipelining, mais vous pouvez toujours rendre SMB3 lent en activant des fonctionnalités coûteuses sans le vouloir.
4. La signature et le chiffrement SMB ne sont pas gratuits. Ils ajoutent un coût CPU par paquet et peuvent désactiver certains offloads NIC. Parfait sur des réseaux hostiles. Mauvais pour « pourquoi c’est 200 MB/s de moins qu’hier ? »
5. La latence pénalise SMB plus qu’on ne le croit. SMB peut pipeliner, mais les charges riches en métadonnées sont toujours bloquées par les allers-retours. Un saut de 2 ms peut écraser les scans de répertoires et les copies de petits fichiers.
6. Les opérations de répertoire sont un sport différent des lectures en streaming. « Je peux lire un gros fichier à 900 MB/s » et « un million de petits fichiers prend des heures » peuvent toutes deux être vraies.
7. Les valeurs par défaut de montage sont prudentes. Les choix par défaut de Linux favorisent la correction et la compatibilité. C’est bien — jusqu’à ce que vous vouliez de la performance et que vous connaissiez votre environnement.
8. SMB Multichannel existe, mais ce n’est pas magique. Il peut utiliser plusieurs NIC/queues, mais seulement si le serveur, le client et la pile réseau sont alignés (et que vous n’êtes pas coincé sur un seul flux TCP par accident).
9. « CIFS lent » est fréquemment « DNS/Kerberos lent ». Les retards d’authentification et les timeouts de résolution de noms peuvent rendre les montages et reconnexions pénibles, même si le débit en régime permanent est correct.

Une citation qui tient toujours en exploitation : L’espoir n’est pas une stratégie. — General Gordon R. Sullivan.

Playbook de diagnostic rapide (trouver le goulot vite)

Si vous ne faites qu’une chose de cet article, faites cette séquence. Elle est conçue pour arrêter le « bingo des options de montage au hasard » et plutôt donner un nom au goulot.

Première étape : confirmez ce que « lent » signifie

• Lent pour l’E/S séquentielle de gros fichiers ? Suspectez la signature/le chiffrement, les limites d’un seul flux TCP, des problèmes MTU, les offloads NIC, ou des limites côté serveur.
• Lent pour les petits fichiers / métadonnées ? Suspectez la latence, la politique de cache d’attributs, l’antivirus côté serveur, les recherches ACL, change notify, ou le comportement d’énumération de répertoire.
• Lent seulement parfois ? Suspectez les referrals DFS, le comportement de reconnexion, le roaming Wi‑Fi, la congestion TCP, les scans en arrière-plan, la contention serveur, ou un pare‑feu faisant une « inspection aidante ».

Deuxième étape : isolez réseau vs stockage vs surcharge du protocole

1. Base réseau : lancez un test iperf3 vers le même serveur (ou même sous‑réseau). Si le réseau ne peut pas faire la vitesse, CIFS ne le pourra pas non plus.
2. Base côté serveur : si possible, testez le débit disque sur le serveur (ou au moins la charge CPU durant les transferts SMB). Si le serveur est saturé par la crypto, vous avez trouvé le coupable.
3. Confirmation du protocole : vérifiez le dialecte SMB négocié, la signature, le chiffrement, et si le multichannel est utilisé.

Troisième étape : changez une chose, mesurez, conservez des preuves

• Commencez par désactiver les fonctions de sécurité coûteuses uniquement si votre posture de sécurité le permet (signature/chiffrement). Sinon, prévoyez du CPU et envisagez AES‑NI, offloads NIC, ou des cœurs plus rapides.
• Puis ajustez le cache et le comportement des attributs selon la charge (magasin d’artefacts CI/CD vs feuilles de calcul partagées vs répertoires home).
• Enfin, adressez la forme de la charge : parallélisme, empaquetage des petits fichiers, flags robocopy/rsync, et exclusions d’indexation/AV côté serveur.

Blague n°1 : le tuning de performance SMB, c’est comme un régime — la plupart du temps la solution est « arrêter de grignoter les appels métadonnées par fichier ».

Étape de base : prouver que c’est CIFS et non votre réseau

Ubuntu 24.04 ne s’est pas réveillé en décidant de gâcher votre journée. Il fait ce que vous avez demandé, avec des paramètres par défaut sûrs mais pas toujours rapides. Avant de toucher aux options de montage, vérifiez ces trois éléments basiques :

• Chemin : montez‑vous la bonne cible (DFS peut vous envoyer ailleurs) ?
• Transport : êtes‑vous sur Ethernet filaire, le bon VLAN, et le bon MTU ?
• Serveur : le serveur SMB est‑il sain, ou est‑il discrètement saturé en CPU à cause de la signature/chiffrement/AV ?

Les plaintes sur le débit SMB sont souvent cross‑team : le réseau dit que c’est le stockage, le stockage dit que c’est le réseau, la sécurité dit « fonctionne comme prévu », et l’équipe applicative a déjà lancé un thread Slack intitulé « Linux est lent ». Votre travail est de transformer des impressions en métriques.

Options de montage qui corrigent généralement le débit

Parlons des options qui déplacent régulièrement l’aiguille sur les clients Ubuntu 24.04. Pas « chaque flag trouvé sur un forum », mais celles qui traitent les goulots communs : négociation de dialecte, coût de la signature/chiffrement, cache et taille des requêtes.

Commencez par une base saine et moderne

Utilisez SMB3 sauf raison legacy très spécifique. Sur Ubuntu 24.04, votre noyau et cifs-utils sont suffisamment modernes pour ça proprement.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino

Ce n’est pas encore le montage « rapide ». C’est le montage « prévisible » :

• vers=3.1.1 : verrouille le dialecte ; évite des rétrogradations étranges.
• nounix : empêche des hypothèses d’extensions POSIX qui peuvent nuire à l’interopérabilité.
• serverino : numéros d’inodes stables fournis par le serveur ; aide certains outils et réduit les surprises.
• soft : renvoie les erreurs plus vite en cas de problème serveur (décidez prudemment ; voir section erreurs).

Gains de débit : réduire le coût par E/S (quand autorisé)

Si votre environnement impose actuellement la signature ou le chiffrement SMB, ne violez pas la politique en production parce que vous avez lu un article. Mais vous devez quand même connaître le coût, sinon vous poursuivrez des flags fantômes pendant des jours.

Option : désactiver la signature (uniquement si la politique le permet)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,seal=no,sign=no,cache=none,actimeo=1

Ce que cela fait : réduit le CPU dépensé pour l’intégrité des messages et/ou le chiffrement. Sur certains réseaux c’est une mauvaise idée. Sur des réseaux internes de confiance, c’est parfois acceptable avec des contrôles compensatoires (segmentation, pare‑feu hôte).

Option : garder la sécurité, mais s’assurer que le CPU n’est pas le goulot

Si vous devez conserver la signature/le chiffrement, traitez‑les comme TLS : il vous faut de la marge CPU et idéalement de l’accélération matérielle (AES‑NI). Si une VM a un faible allocation vCPU ou des voisins bruyants, le débit ressemblera à un problème de protocole.

Workloads riches en métadonnées : options de cache qui comptent

Les sémantiques de cache par défaut sont prudentes. C’est bon pour la correction multi‑clients. Ça peut aussi rendre chaque build ou opération d’extraction aussi lente que la mélasse.

cache=strict vs cache=none

• cache=none : moins de surprises ; souvent plus lent pour les lectures répétées et les métadonnées.
• cache=strict : peut accélérer les lectures tout en restant relativement correct, mais peut quand même être limité par les appels métadonnées.

actimeo (timeout du cache d’attributs)

Pour les charges qui exécutent fréquemment stat() sur des fichiers (systèmes de build, scanners de dépendances), augmenter le cache d’attributs peut être transformateur.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,cache=strict,actimeo=30

Compromis : vous acceptez que les attributs puissent être obsolètes jusqu’à 30 secondes. Pour des « répertoires home partagés » cela peut être gênant. Pour un « cache d’artefacts en lecture majoritaire » c’est généralement acceptable et rapide.

Performance petits fichiers : vous ne pouvez pas contourner la physique par une option de montage

SMB doit effectuer plusieurs opérations par fichier : create/open, query info, read/write, close, mise à jour des métadonnées. Multipliez par 500 000 fichiers et vous obtiendrez un benchmark de latence.

Les options de montage aident un peu (cache, moins d’aller‑retours), mais les gros gains sont souvent : réduire le nombre de fichiers (tar), augmenter le parallélisme prudemment, ou déplacer la charge vers du stockage objet / SSD local temporaire puis synchroniser.

Gros fichiers : attention au piège du flux unique

Beaucoup d’opérations « copier un gros fichier » sont en fait un seul flux TCP. Sur des liens haut débit et latence modérée, un flux unique peut sous‑utiliser la conduite sauf si window scaling, contrôle de congestion et tailles de buffer sont corrects. SMB Multichannel peut aider, mais uniquement quand il est négocié et supporté.

Blague n°2 : Le transfert SMB le plus rapide est celui que votre équipe sécurité ne vous a pas forcé à chiffrer — malheureusement, ils le remarquent généralement.

Pourquoi la forme de votre charge importe (gros vs petits fichiers)

En production, « CIFS est lent » signifie typiquement une des options suivantes :

• Les lectures/écritures séquentielles de gros fichiers sont lentes : vous payez l’impôt crypto/signature, vous êtes coincé sur un chemin unique, ou le stockage serveur est saturé.
• Les petits fichiers sont lents : la latence et les opérations métadonnées dominent ; le cache et le scanning côté serveur comptent plus que le débit brut.
• L’énumération de répertoire est lente : vous parcourez de très grands répertoires, vous subissez le coût d’évaluation des ACL, ou votre client effectue des stat supplémentaires.
• Le montage/la connexion est lente : DNS, Kerberos, décalage d’heure, ou des tentatives de setup SMB qui échouent.

Choisissez le bon outil. Si vous devez déplacer des millions de petits fichiers chaque nuit, SMB peut le faire, mais vous devez l’aborder comme un problème d’ingénierie de charge, pas comme un problème de ligne de montage.

12+ tâches pratiques : commandes, sorties, décisions

Voici les vraies vérifications que je lance quand quelqu’un dit « CIFS est douloureusement lent ». Chaque tâche inclut une commande, une sortie réaliste, et la décision que vous en tirez. Exécutez‑les dans l’ordre si vous le souhaitez ; elles fonctionnent aussi à la carte.

Tâche 1 : Confirmer le noyau, versions de cifs-utils (vous déboguez une cible mouvante)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | egrep 'cifs-utils|linux-modules-extra' | head
ii  cifs-utils                    2:7.0-2ubuntu0.1   amd64  Common Internet File System utilities
ii  linux-modules-extra-6.8.0-41-generic  6.8.0-41.41 amd64  Linux kernel extra modules for version 6.8.0

Décision : Si linux-modules-extra manque, vous pouvez perdre des modules optionnels et des outils. Si le noyau est ancien (pas votre cas sur 24.04), mettez à jour avant d’ajuster.

Tâche 2 : Vérifier les détails de montage et les fonctionnalités SMB négociées

cr0x@server:~$ mount | grep 'type cifs'
//fs01.corp.example/engineering on /mnt/eng type cifs (rw,relatime,vers=3.1.1,cache=strict,username=alice,uid=1000,gid=1000,soft,serverino,actimeo=1)

Décision : Confirmez que vous utilisez bien SMB3.1.1, et voyez cache/actimeo. Si vous attendiez un flag de tuning et qu’il n’est pas présent, vous ne testez pas ce que vous croyez tester.

Tâche 3 : Récupérer les paramètres de session SMB depuis le noyau (dialecte, signature, chiffrement)

cr0x@server:~$ sudo cat /proc/fs/cifs/DebugData | sed -n '1,120p'
CIFS Version 2.48
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY
Active VFS Requests: 0
Servers:
1) Name: fs01.corp.example
   TCP status: connected
   Dialect: 3.1.1
   Security: signing required
   Encryption: yes
   Session User: CORP\alice
Shares:
1) \\fs01.corp.example\engineering
   Mounts: 1
   UNC: \\fs01.corp.example\engineering
   Options: rw,relatime,soft,serverino,actimeo=1,cache=strict

Décision : Si la signature est requise et le chiffrement activé, attendez‑vous à un coût CPU. Si le débit est bas et que le CPU est élevé d’un côté ou de l’autre, vous avez probablement trouvé le limiteur.

Tâche 4 : Base réseau avec iperf3

cr0x@server:~$ iperf3 -c fs01.corp.example -P 4 -t 10
Connecting to host fs01.corp.example, port 5201
[SUM]   0.00-10.00  sec  9.45 GBytes  8.12 Gbits/sec  sender
[SUM]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec  receiver

Décision : Le réseau peut faire ~8 Gbit/s, donc une copie SMB à 100–200 Mbit/s n’est pas « le réseau ». Maintenant vous pouvez arrêter de discuter avec l’équipe réseau et commencer à discuter avec des preuves.

Tâche 5 : Confirmer la stabilité du chemin (DNS, reverse lookups, referrals)

cr0x@server:~$ getent hosts fs01.corp.example
10.20.30.40   fs01.corp.example
cr0x@server:~$ smbclient -L fs01.corp.example -U 'CORP\alice' -m SMB3 | head
	Sharename       Type      Comment
	---------       ----      -------
	engineering     Disk
	IPC$            IPC       IPC Service (SMB Server)
SMB1 disabled -- no workgroup available

Décision : Si la résolution de nom est lente ou bascule entre IPs, corrigez cela d’abord. Si SMB1 est en jeu, vous êtes en territoire legacy et la performance sera imprévisible.

Tâche 6 : Mesurer le débit réel de copie d’un gros fichier

cr0x@server:~$ dd if=/dev/zero of=/mnt/eng/test-10g.bin bs=16M count=640 oflag=direct status=progress
10737418240 bytes (11 GB, 10 GiB) copied, 33 s, 325 MB/s
640+0 records in
640+0 records out
10737418240 bytes copied, 33.0589 s, 325 MB/s

Décision : Si le débit pour gros fichiers est faible, concentrez‑vous sur la signature/le chiffrement, multichannel, offloads NIC, CPU serveur et le stockage sous‑jacent. Si le gros fichier est correct mais que les petits fichiers sont catastrophiques, passez à la partie métadonnées/cache et changements de workflow.

Tâche 7 : Mesurer la douleur des métadonnées (boucle create/stat/unlink)

cr0x@server:~$ time bash -c 'd=/mnt/eng/meta-test; mkdir -p "$d"; for i in $(seq 1 20000); do echo x > "$d/f$i"; done; sync'
real	2m3.412s
user	0m8.941s
sys	0m47.228s

Décision : Si cela prend des minutes pour 20k petits fichiers, vous êtes limité par la latence/métadonnées. Envisagez actimeo, des exclusions AV côté serveur, empaqueter les fichiers, ou déplacer le workflow hors de SMB.

Tâche 8 : Vérifier la saturation CPU côté client pendant les transferts

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0-41-generic (cr0x) 	12/30/2025 	_x86_64_	(8 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:10:02 PM  all  12.10   0.00  22.55    0.20  0.00   1.10    0.00  64.05
12:10:02 PM    3  70.00   0.00  25.00    0.00  0.00   2.00    0.00   3.00

Décision : Un cœur saturé tandis que les autres sont au repos signifie souvent du travail crypto/signature par connexion, un flux unique, ou un outil de copie mono‑thread. Envisagez multichannel, parallélisme, ou réduire la charge de sécurité (si autorisé).

Tâche 9 : Vérifier vitesse/duplex NIC et erreurs (la réalité est cruelle)

cr0x@server:~$ sudo ethtool eno1 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes
cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
  9812134321  8123123      0      12       0  112233
    TX:  bytes packets errors dropped carrier collsns
  8741123988  7012231      0       0       0       0

Décision : Les erreurs/paquets perdus signifient des retransmissions, que SMB interprétera comme « pourquoi tout est lent ? ». Corrigez les problèmes physiques/réseau avant de tuner le protocole.

Tâche 10 : Valider le MTU bout en bout (les problèmes PMTUD ressemblent à la lenteur SMB)

cr0x@server:~$ ping -c 3 -M do -s 1472 fs01.corp.example
PING fs01.corp.example (10.20.30.40) 1472(1500) bytes of data.
1480 bytes from 10.20.30.40: icmp_seq=1 ttl=62 time=0.412 ms
1480 bytes from 10.20.30.40: icmp_seq=2 ttl=62 time=0.396 ms
1480 bytes from 10.20.30.40: icmp_seq=3 ttl=62 time=0.401 ms

--- fs01.corp.example ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.396/0.403/0.412/0.007 ms

Décision : Si vous obtenez « Frag needed » ou des timeouts, votre situation jumbo/PMTUD est cassée. Corrigez‑la ; SMB arrêtera de caler.

Tâche 11 : Vérifier SMB multichannel et RDMA (si vous l’attendiez)

cr0x@server:~$ sudo grep -iE 'SMB_DIRECT|RDMA|Multi' /proc/fs/cifs/DebugData
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY

Décision : Voir SMB_DIRECT dans les features ne signifie pas que vous l’utilisez. Si vous avez besoin de RDMA/Direct, vérifiez le support serveur et que votre pile NIC/driver est configurée. Sinon, supposez TCP classique.

Tâche 12 : Détecter la « taxe sécurité » en basculant une politique de partage de test (en labo)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/lab-nosign /mnt/lab \
  -o vers=3.1.1,username=alice,domain=CORP,sign=no,seal=no,cache=strict,actimeo=30
cr0x@server:~$ dd if=/dev/zero of=/mnt/lab/test-5g.bin bs=16M count=320 oflag=direct status=progress
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 9 s, 594 MB/s

Décision : Si la performance double dans un test contrôlé quand la signature/le chiffrement sont désactivés, votre « mystère » est un coût de politique. Escaladez avec des chiffres, pas des plaintes : « le chiffrement réduit le débit d’environ 45 % sur cette classe de clients ».

Tâche 13 : Confirmer que le serveur ne bride pas via les paramètres de partage (exemple Windows depuis Linux)

cr0x@server:~$ smbclient //fs01.corp.example/engineering -U 'CORP\alice' -m SMB3 -c 'get test-10g.bin /dev/null; quit'
getting file \test-10g.bin of size 10737418240 as /dev/null (312.4 MB/s) (average 312.4 MB/s)

Décision : Si smbclient est rapide mais le montage noyau est lent, ce sont vos options de montage/cache/behaviour client le problème. Si les deux sont lents, regardez serveur/réseau.

Tâche 14 : Inspecter dmesg pour des avertissements CIFS (les retries silencieux ralentissent)

cr0x@server:~$ sudo dmesg -T | egrep -i 'cifs|smb3' | tail -n 12
[Mon Dec 30 12:02:11 2025] CIFS: VFS: \\fs01.corp.example has not responded in 180 seconds. Reconnecting...
[Mon Dec 30 12:02:12 2025] CIFS: VFS: cifs_reconnect: reconnect to server fs01.corp.example

Décision : Toute reconnexion, timeout ou « server not responding » signifie que vous déboguez la stabilité d’abord. Le tuning de débit sur une session instable, c’est du cosplay performance.

Tâche 15 : Confirmer la synchronisation temporelle (les bizarreries Kerberos/autorisation ralentissent les montages/reconnexions)

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-30 12:12:44 UTC
           Universal time: Mon 2025-12-30 12:12:44 UTC
                 RTC time: Mon 2025-12-30 12:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Décision : Si l’heure n’est pas synchronisée, corrigez‑la avant de blâmer CIFS. Kerberos et l’établissement de sessions sécurisées se comportent mal en cas de dérive.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

L’entreprise : une SaaS de taille moyenne, services de fichiers Windows pour artefacts d’ingénierie partagés. Une équipe a migré ses runners de build d’Ubuntu 22.04 vers 24.04. Le premier lundi après le déploiement, les temps de build ont gonflé. Les gens ont blâmé « le nouveau noyau Ubuntu » et ont commencé à pinner d’anciennes images.

La mauvaise hypothèse était subtile : ils supposaient que les caractéristiques de performance du partage étaient stables parce que « le serveur n’avait pas changé ». Mais le serveur avait subi un durcissement de sécurité deux semaines plus tôt — le chiffrement SMB avait été activé pour ce partage uniquement. Les anciens runners atteignaient toujours un autre chemin de partage à cause d’un cache de referral DFS obsolète dans leurs configs, contournant effectivement le chemin chiffré. Les nouveaux runners ont résolu correctement le referral et sont arrivés sur la cible chiffrée.

Sur le papier, c’était « conforme au design ». En réalité, c’était un incident de production : la capacité de build a chuté, les pipelines ont été mis en file, et l’on‑call a dû expliquer pourquoi des « améliorations de sécurité » avaient un coût non mesuré.

La correction n’était pas une option de montage magique. C’était une décision : soit conserver le chiffrement et provisionner plus de CPU côté serveurs SMB (et garantir AES‑NI sur la classe de VM), soit segmenter le réseau et autoriser SMB non chiffré sur ce chemin interne avec contrôles compensatoires. Ils ont choisi la première pour les dépôts sensibles, et ont créé un partage non chiffré pour les caches non sensibles.

Leçon : les baselines de performance doivent inclure la posture de sécurité. Si vous ne la mesurez pas, vous la « découvrirez » à 2 h du matin.

Mini-histoire n°2 : L’optimisation qui a mal tourné

Une organisation finance avait un cluster analytics Ubuntu montant un partage CIFS pour des dépôts CSV nocturnes. Quelqu’un a remarqué que le montage utilisait cache=none et actimeo=1, et a décidé de « l’accélérer » en poussant actimeo=600 et en activant strict caching partout.

Le débit s’est amélioré. Les scans de répertoire se sont accélérés. Tout le monde a brièvement fêté ça.

Puis les alertes qualité des données ont commencé. Un job en aval a lu des fichiers qui avaient été remplacés sur le partage, mais le client conservait les attributs en cache suffisamment longtemps pour que le pipeline pense « fichier inchangé » et saute l’ingestion. Le changement de cache était correct pour la performance et faux pour la sémantique. Le business se moquait du tuning SMB ; il se souciait des rapports obsolètes.

Ils ont fait marche arrière et ont remplacé cela par un design ennuyeux : le producteur écrit dans un répertoire de staging, puis fait un rename atomique dans un répertoire « ready ». Les consommateurs lisent seulement « ready » et utilisent des checksums de contenu. Avec ce workflow, actimeo=30 était sûr et efficace.

Leçon : ne touchez pas au cache avant de comprendre votre modèle de correction. SMB n’est pas votre base de données. Votre pipeline a encore besoin de règles.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait plusieurs flottes Linux montant des partages Windows pour profils utilisateurs et configs applicatives. Chaque trimestre, quelqu’un se plaignait : « CIFS est redevenu lent. » Au lieu de faire des tweaks aléatoires, l’équipe SRE avait une habitude ennuyeuse : un benchmark répétable et une simple page de « profils de montage connus bons ».

Ils maintenaient deux profils : Interactive (home dirs, correction d’abord) et Bulk (caches read‑mostly, débit d’abord). Les deux étaient codifiés dans la gestion de configuration, avec un petit canari qui exécutait smbclient et un test dd monté noyau quotidiennement. Les résultats étaient graphiés à côté du CPU serveur, des drops réseau et des échecs d’authentification.

Quand une mise à jour firmware de stockage a introduit une perte de paquets intermittente sur un switch top‑of‑rack, les graphes SMB ont chuté avant que les utilisateurs ne crient. Le canari a aussi montré des messages de reconnexion dans dmesg. Le réseau a d’abord hausser les épaules parce que « les liens sont hauts ». Les données ont été irritablement spécifiques : erreurs sur un seul port NIC, sur un rack, corrélées aux reconnexions SMB et à l’effondrement du débit.

Ils ont corrigé un problème de couche physique et ont restauré la performance sans toucher une seule option de montage. La pratique ennuyeuse n’était pas des exploits. C’était de l’instrumentation et une baseline documentée.

Leçon : le tuning CIFS le plus rapide est de prouver que vous n’avez pas besoin de tuning CIFS.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Gros fichiers limités à 30–80 MB/s sur 10 GbE

Cause racine : signature/chiffrement SMB requis ; CPU client ou serveur saturé ; limitations d’un flux TCP unique.

Correction : Vérifiez signature/chiffrement via /proc/fs/cifs/DebugData. Si la politique le permet, testez seal=no,sign=no sur un partage labo. Sinon, ajoutez du CPU, assurez AES‑NI, envisagez SMB multichannel, et confirmez que les offloads NIC ne sont pas désactivés par la politique.

2) Symptom : Millions de petits fichiers prennent une éternité, mais les gros fichiers vont bien

Cause racine : allers‑retours métadonnées et latence ; cache d’attributs trop strict ; antivirus côté serveur scannant chaque open/close.

Correction : Augmentez actimeo prudemment (par ex. 10–30) pour les workloads read‑mostly ; empaquetez les petits fichiers en archives ; ajoutez du parallélisme ; coordonnez les exclusions AV sur le partage pour des chemins sûrs connus.

3) Symptom : L’énumération de répertoire est douloureusement lente

Cause racine : répertoires énormes ; coût d’évaluation des ACL ; client effectuant des stat supplémentaires ; bounce de referral DFS.

Correction : Évitez les répertoires plats géants ; segmentez par préfixe/date/projet. Confirmez la cible stable et l’absence de surprises DFS. Utilisez le cache approprié selon vos besoins de cohérence.

4) Symptom : Les montages bloquent 30–60 secondes, puis fonctionnent

Cause racine : timeouts DNS, stalls de reverse lookup, retries Kerberos, dérive horaire, délais d’inspection pare‑feu.

Correction : Corrigez la résolution de noms ; vérifiez la synchro temporelle ; validez la config Kerberos ; consultez les logs pare‑feu ; préférez des FQDN stables ; évitez les enregistrements multi‑A sauf si vous savez comment les clients choisissent.

5) Symptom : Reconnexions « server not responding » aléatoires sous charge

Cause racine : perte de paquets, problèmes MTU/PMTUD, NIC/driver instable, ou serveur surchargé atteignant des timeouts.

Correction : Vérifiez erreurs/drops d’interface ; confirmez le MTU avec ping -M do ; cherchez des reconnexions CIFS dans dmesg ; corrigez la stabilité du transport avant le tuning.

6) Symptom : Après un « tuning de performance », les applis voient des données obsolètes

Cause racine : cache d’attributs agressif (actimeo) utilisé sur un partage sensible à la cohérence.

Correction : Réduisez actimeo (1–5) ou utilisez le profil sûr ; redesign du workflow en utilisant des renames atomiques et des répertoires ready/staging.

7) Symptom : Les clients Linux sont plus lents que Windows pour le même partage

Cause racine : fonctionnalités négociées différentes, exigences de signature différentes par politique client, valeurs par défaut de cache différentes, ou chemin différent (DFS).

Correction : Comparez les paramètres négociés des deux côtés. Ne comparez pas un client Windows sur le même VLAN avec une VM Linux à travers un pare‑feu et appelez cela de la science.

8) Symptom : Le débit s’effondre seulement sur Wi‑Fi ou VPN

Cause racine : latence et perte ; MTU VPN ; flux TCP unique ; inspection de paquets.

Correction : Utilisez le split tunneling si autorisé ; corrigez le MTU ; utilisez des transferts parallèles ; envisagez de déplacer les opérations massives hors SMB dans les scénarios distants.

Listes de contrôle / plan pas à pas

Pas à pas : de la plainte à la correction sans deviner

1. Classifiez la lenteur : gros fichier vs petit fichier vs énumération de répertoire vs temps de montage.
2. Prouvez la capacité réseau avec iperf3 (flux parallèles).
3. Confirmez les fonctionnalités SMB négociées via /proc/fs/cifs/DebugData : dialecte, signature, chiffrement.
4. Mesurez un transfert contrôlé de gros fichier (I/O direct) pour enlever les illusions du cache de pages.
5. Mesurez un test contrôlé de métadonnées (boucle create/stat/unlink).
6. Vérifiez la stabilité : erreurs NIC, MTU, logs de reconnexion CIFS.
7. Si la taxe sécurité est suspectée : testez dans un partage labo avec signature/chiffrement désactivés ; quantifiez le delta.
8. Choisissez un profil de montage :
   • Correction d’abord : cache=none ou actimeo prudent.
   • Read‑mostly/bulk : cache=strict,actimeo=30 (ou plus si le workflow le garantit).
9. Adressez la forme de la charge : tar des petits fichiers, parallélisez, stagez localement, évitez les répertoires gigantesques.
10. Codifiez : placez les options de montage dans /etc/fstab (ou unités systemd mount) avec des commentaires et un propriétaire.
11. Prévenir les régressions : gardez un petit benchmark/canari et alertez sur les écarts.

Deux profils de montage que vous pouvez réellement utiliser

Profil A : Interactif / correction d’abord (home dirs, éditions partagées)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/homes /home \
  -o vers=3.1.1,sec=krb5,cache=none,actimeo=1,soft,serverino,uid=1000,gid=1000

À utiliser quand : plusieurs écrivains, personnes éditant les mêmes fichiers, la correction prime sur la vitesse.

Profil B : Bulk read‑mostly (cache d’artefacts, jeux de données, médias)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/artifacts /mnt/artifacts \
  -o vers=3.1.1,username=buildbot,domain=CORP,cache=strict,actimeo=30,serverino,uid=1000,gid=1000

À utiliser quand : lecture majoritaire, peu d’écrivains, vous pouvez tolérer une certaine obsolescence d’attributs.

FAQ

1) Pourquoi CIFS est‑il devenu plus lent sur Ubuntu 24.04 comparé à 22.04 ?

Habituellement il ne « devient » pas plus lent isolément. Ce qui change, ce sont les fonctionnalités SMB négociées (dialecte, signature, chiffrement), le comportement du noyau, ou votre environnement (politique de sécurité, DNS, chemin réseau). Confirmez via /proc/fs/cifs/DebugData et comparez.

2) Quelle option de montage donne le plus grand gain de débit ?

Si vous êtes limité par la CPU à cause des fonctions de sécurité, le plus gros « boost » vient de la désactivation de la signature/le chiffrement — uniquement si la politique le permet. Si vous ne pouvez pas, les gains suivants sont d’assurer assez de CPU et d’utiliser un cache approprié (cache=strict, actimeo raisonnable) pour les workloads read‑mostly.

3) Dois‑je toujours définir actimeo=30 ?

Non. C’est excellent pour les workloads read‑mostly et catastrophique pour les partages sensibles à la correction avec des changements fréquents. Traitez‑le comme un réglage qui change la sémantique, pas comme un gain gratuit de vitesse.

4) Le réglage rsize/wsize a‑t‑il encore de l’importance ?

Moins qu’avant, car SMB2/3 et le client noyau gèrent dynamiquement la taille. Cela peut encore compter dans des cas limites (appliances, middleboxes étranges), mais ce n’est pas mon levier premier sur Ubuntu 24.04.

5) Pourquoi l’énumération de répertoire est lente alors que le débit est bon ?

Parce qu’énumérer n’est pas du travail de débit ; c’est du travail métadonnées. Chaque entrée peut nécessiter des requêtes d’attributs et des vérifications ACL, et les grands répertoires amplifient la latence. Corrigez avec une meilleure organisation des répertoires, du cache quand c’est sûr, et une politique de scanning côté serveur.

6) soft est‑il sûr à utiliser ?

Ça dépend. soft peut causer des E/S à renvoyer des erreurs au lieu de bloquer indéfiniment, ce qui peut être souhaitable pour des jobs batch. Pour des workloads de type base de données, des erreurs I/O inattendues peuvent être pires que l’attente. Choisissez intentionnellement, pas par cargo‑cult.

7) Dois‑je utiliser sec=krb5 ou username/password ?

Kerberos (sec=krb5) est généralement plus propre pour les environnements d’entreprise et évite la prolifération de mots de passe, mais il est plus sensible au DNS et à la synchro temporelle. Si les montages sont lents ou instables, validez NTP et les tickets Kerberos.

8) SMB Multichannel peut‑il résoudre mes problèmes de vitesse ?

Il peut, surtout sur des liens rapides où un flux TCP unique sous‑utilise la bande passante. Mais il nécessite le support serveur et une configuration réseau/NIC correcte. Ne supposez pas qu’il est activé ; vérifiez et testez.

9) Pourquoi smbclient semble plus rapide que le système de fichiers monté ?

smbclient emprunte un chemin client différent et une charge différente. S’il est rapide alors que le montage est lent, regardez les options de montage, la sémantique de cache, et les modèles d’accès applicatifs (beaucoup de stat/open). Si les deux sont lents, regardez serveur/réseau/politique.

10) Quelle est la façon la plus rapide de déplacer un million de petits fichiers ?

Ne le faites pas. Emballez‑les (tar/zstd), déplacez un seul gros blob, puis décompressez localement. Si vous devez conserver des fichiers individuels, utilisez le parallélisme et acceptez que les métadonnées dominent. SMB n’est pas un store d’objets haute performance.

Conclusion : que faire ensuite

Quand CIFS est douloureusement lent sur Ubuntu 24.04, la correction est rarement « ajouter des flags au hasard ». Faites la chose disciplinée :

1. Lancez le playbook de diagnostic rapide. Identifiez si vous êtes limité par le débit, les métadonnées, ou la stabilité.
2. Confirmez les fonctionnalités SMB négociées. Si la signature/le chiffrement sont requis, considérez‑les comme une exigence de capacité, pas un mystère.
3. Choisissez un profil de montage adapté à la charge : correction d’abord pour les partages interactifs, cache pour le bulk read‑mostly.
4. Changez la forme de la charge si vous déplacez de petits fichiers : empaquetez, stagez localement, parallélisez prudemment, évitez les répertoires massifs.
5. Codifiez les options de montage et gardez un petit canari de benchmark pour remarquer les régressions avant les utilisateurs.

Si vous voulez une action pratique : capturez /proc/fs/cifs/DebugData, un résultat iperf3, et un test dd gros‑fichier. Avec ces trois artefacts, vous pouvez avoir une conversation adulte avec réseau, stockage et sécurité — sans deviner.