Partage de fichiers Linux : NFS vs SMB — Choisissez celui qui ne se bloque pas aléatoirement

Ce que signifie généralement « se bloquer aléatoirement »

Quand les gens disent « le partage de fichiers se bloque », ils veulent en général dire une des trois choses suivantes :

• Pics de latence : les opérations retournent, mais prennent parfois des secondes ou des minutes. Les applications expirent, les tentatives se cumulent et vous obtenez un thundering herd.
• Attentes I/O dures : un processus se bloque dans l’espace noyau (souvent en état D) en attendant le serveur ou le réseau. Votre kill -9 ne change rien. Ce n’est pas que le processus fait l’obstiné ; c’est le noyau qui attend l’I/O.
• Interblocages sémantiques : verrous de fichier ou oplocks/leases qui interagissent avec le cache client et les attentes de l’application. Tout est « up », mais l’application ne progresse pas.

Les deux protocoles, NFS et SMB, peuvent produire ces trois cas. La différence tient à où la panne se manifeste, à la vitesse à laquelle elle devient évidente et aux réglages dont vous disposez pour la rendre ennuyeuse plutôt que catastrophique.

Un modèle mental utile : les systèmes de fichiers réseau sont des systèmes distribués avec des bords tranchants. Et les systèmes distribués font bien deux choses : ils échouent de nouvelles façons et ils vous forcent à apprendre les timeouts.

Quelques faits et une histoire qui comptent vraiment

Un peu de contexte aide car de vieilles décisions de conception expliquent aujourd’hui le fameux « pourquoi ce comportement par défaut ? »

1. NFS a été conçu par Sun dans les années 1980, à une époque où le modèle de sécurité était essentiellement le « LAN de confiance ». C’est pourquoi la sécurité est greffée en couches (AUTH_SYS, puis Kerberos via RPCSEC_GSS).
2. NFSv3 est sans état (le serveur ne suit pas l’état de session client de la même façon). Cela peut être excellent pour la récupération, et terrible pour les attentes de verrouillage sans services supplémentaires.
3. NFSv4 a introduit la notion d’état (verrous, délégations, sessions), ce qui améliore la sémantique mais augmente les modes de panne liés à la confusion d’état quand le réseau clignote.
4. SMB a commencé comme un protocole LAN pour DOS/Windows et a accumulé des fonctionnalités d’entreprise : ACL riches, négociation, et l’hypothèse que l’identité importe (utilisateurs, domaines, services d’annuaire).
5. SMB1 est ancien et dangereux ; les environnements modernes doivent être sur SMB3.x. SMB3 a apporté chiffrement, multichannel, meilleurs comportements de performance et moins d’artéfacts archéologiques.
6. Samba (le serveur SMB sur Linux) est en production depuis des décennies. Ce n’est pas « un bricolage de compatibilité ». C’est un moteur sérieux de traduction identité–système de fichiers.
7. La signature de paquets et le chiffrement sont devenus courants dans de nombreux environnements Windows d’entreprise. C’est bon pour la sécurité, mais peut devenir une taxe de performance accidentelle.
8. NFS sur TCP a remplacé UDP pour des raisons de robustesse dans la plupart des déploiements sérieux. UDP existe encore dans les recoins, souvent là où vous ne voulez pas de surprises.
9. « Stale file handle » est une erreur classique NFS liée à la façon dont NFS identifie fichiers et répertoires lors de changements côté serveur. Ce n’est pas aléatoire ; c’est votre serveur/export qui a changé sous des clients actifs.

Une citation utile, parce que les ingénieurs méritent une ligne de poésie : L’espoir n’est pas une stratégie. (idée paraphrasée, souvent citée en exploitation)

Comment NFS se comporte réellement en cas de panne

NFS est simple jusqu’à ce qu’il ne le soit plus : le problème du « blocage dans le noyau »

Les clients NFS sont optimisés pour ressembler à des appels de système de fichiers locaux. C’est le principe. La VFS du noyau envoie un RPC, attend le serveur et renvoie les données. Quand le serveur est lent, inaccessible, surchargé ou perd des paquets, ces attentes noyau peuvent se transformer en blocages applicatifs.

La distinction la plus importante pour les montages NFS en production est : hard vs soft. La deuxième plus importante est : timeouts et retrans qui rendent votre mode de panne explicite au lieu d’indéfini.

• montages hard : le client retente l’I/O indéfiniment. Cela protège la cohérence des données pour de nombreuses charges, mais peut bloquer les processus longtemps. « Indéfiniment » n’est pas une impression ; c’est une politique.
• montages soft : le client abandonne et renvoie une erreur à l’application après des tentatives. Cela évite les blocages infinis mais risque la corruption des données pour certains patterns d’écriture (applications qui n’attendent pas des échecs partiels).

La plupart des équipes Linux sérieuses utilisent hard mais ajustent les timeouts et utilisent l’automount de façon sensée pour réduire le rayon d’impact. Si vous faites tourner des bases de données sur NFS, vous savez déjà que c’est une douleur particulière qui ne fonctionne que si vous êtes extrêmement disciplinés.

Verrouillage : NFSv3 vs NFSv4, et pourquoi votre appli s’en préoccupe

Le verrouillage de fichiers en NFSv3 impliquait historiquement des services séparés (lockd/statd). Si ceux-ci sont mal configurés, filtrés par un pare-feu ou cassés par du NAT, vous pouvez obtenir un comportement « ça marche mais parfois non » qui ressemble à des blocages aléatoires.

NFSv4 intègre le verrouillage dans le protocole et est généralement recommandé pour les nouveaux designs. Mais NFSv4 est avec état : serveur et client gardent la trace des sessions et des verrous. Si votre réseau clignote, vous pouvez obtenir expiration de baux, tempêtes de récupération et applications qui stagnent pendant la réconciliation d’état.

Cache client et cohérence des attributs

Les clients NFS mettent en cache données et attributs. C’est utile ; sinon votre serveur de métadonnées fondrait. Mais cela signifie que « j’ai créé un fichier et un autre hôte ne le voit pas » peut être un comportement attendu si votre cache d’attributs est agressif.

Sur Linux, des options de montage comme actimeo, acregmin, acregmax et les sémantiques v4 autour des délégations influencent si vous obtenez des lectures rapides ou cohérentes. Mal choisir et vos systèmes de build se comporteront comme des maisons hantées.

Deux signatures d’échec NFS qui reviennent souvent

• Stale file handle : des changements côté serveur (p. ex. export déplacé, inode réutilisé, rollback de snapshot, basculement sans file handles stables) invalident les références clients.
• Tempêtes de récupération : après un reboot serveur ou un clignotement réseau, de nombreux clients rétablissent l’état en même temps, rendant le serveur lent, ce qui pousse les clients à reculer, ce qui le rend encore plus lent. Félicitations, vous avez inventé du trafic.

Comment SMB se comporte réellement en cas de panne

SMB est bavard par conception, mais le SMB moderne est plus malin qu’on ne le pense

SMB a la réputation chez les Linuxiens d’être « ce truc Windows ». En réalité, SMB3 est un protocole capable avec des fonctionnalités que NFS n’égale pas toujours en standard : ACL riches, intégration mature à Active Directory, chiffrement, et des options haute performance comme multichannel.

Mais SMB impose aussi une lourde charge opérationnelle : identité, DNS, synchronisation horaire, contrôleurs de domaine et politiques. Quand SMB se bloque, ce n’est souvent pas « le stockage » du tout. C’est l’auth, la résolution de noms ou une fonction de sécurité qui fait exactement ce pour quoi elle est programmée.

Patrons typiques de blocage SMB sur clients Linux

• Problèmes de renouvellement de credentials ou tickets : les tickets Kerberos expirent, les renouvellements échouent et votre montage devient curieusement lent ou génère des erreurs.
• Problèmes DNS / SPN : le nom serveur utilisé par les clients ne correspond pas à ce que Kerberos attend, entraînant une auth de repli ou des échecs répétés.
• Surcharge due à la signature/chiffrement : si la signature est requise partout et que les CPUs sont faibles ou occupés, SMB devient un benchmark crypto déguisé en I/O fichier.
• Surprises d’oplocks/leases : le cache client SMB (oplocks/leases) peut améliorer les performances mais aussi causer des moments « pourquoi ce fichier est verrouillé » quand des applications attendent une sémantique de type POSIX.

Permissions SMB : l’iceberg caché

Si vous avez besoin d’ACL à la Windows et d’un comportement cohérent avec des identités AD, SMB est généralement la voie la plus propre. NFS peut aussi le faire avec les ACL NFSv4 et le mappage d’identités, mais « peut » et « agréable » sont des mots différents.

Sur des clients Linux montant des partages SMB via cifs, vous mappez souvent les ACL Windows en vues de permissions POSIX. Ce mapping peut tromper les outils. Les utilisateurs voient chmod « réussir » et supposent que quelque chose a changé ; ce n’est pas forcément le cas. Cette confusion devient des tickets, puis des escalades, puis vous.

Blague #1 : SMB signifie Server Message Block, mais dans le chat d’incident c’est parfois « Seriously, My Build ». (jeu de mots)

Choisir le protocole : règles de décision valables à 3 h du matin

Si vous êtes Linux-vers-Linux et voulez le moins de drame : par défaut NFSv4.1+

Pour des clients Linux et un serveur Linux ou NAS d’entreprise, NFSv4.1 (ou plus récent) est typiquement le choix le plus simple et fiable. Il est bien supporté, performant et ne nécessite pas tout l’univers d’identité Windows.

À utiliser quand :

• Vous voulez la sémantique POSIX directe la plupart du temps.
• Vous pouvez gérer un petit ensemble d’exports et de clients.
• Vous vous souciez des performances par CPU et d’un comportement prévisible sous charge.
• Vous pouvez mettre en œuvre Kerberos si les données le justifient.

Si votre source d’identité est Active Directory et que les clients Windows sont majoritaires : choisissez SMB3

Si l’entreprise vit dans AD (cycle de vie des utilisateurs, GPO, clients Windows), SMB est le chemin de moindre résistance. Samba peut servir aussi des clients Linux, mais le centre de gravité reste la sémantique et les outils Windows.

À utiliser quand :

• Vous avez besoin de compatibilité ACL style NTFS et d’attentes d’audit.
• Vous voulez une expérience cohérente entre clients Windows et Linux sur le même partage.
• Vous avez besoin du chiffrement SMB parce que vous ne contrôlez pas le chemin réseau.

Quand les « blocages aléatoires » sont inacceptables, préférez le protocole dont la panne peut être visible pour l’appli

C’est la partie inconfortable. Un NFS monté en hard peut bloquer des processus indéfiniment. SMB peut aussi bloquer, mais dans beaucoup d’environnements la pile client et les outils en espace utilisateur rendent plus évident quand l’auth ou la résolution de noms est en cause.

Si vous exécutez des jobs batch où échouer rapidement vaut mieux que bloquer, vous pouvez argumenter en faveur de SMB avec timeouts stricts ou de NFS avec des comportements soft soigneusement réfléchis (mais restez conservateur).

N’utilisez pas les deux protocoles sur le même système de fichiers à moins de connaître les sémantiques

Servir le même répertoire via NFS et SMB en même temps est un piège classique. Les sémantiques de verrouillage et de cache peuvent diverger. Si vous devez le faire, testez exactement les comportements applicatifs qui vous importent (patterns de rename, écritures atomiques, verrous de fichier et visibilité des changements de répertoire).

Blague #2 : La seule chose pire qu’un montage NFS bloqué est une réunion intitulée « Standardisons le partage de fichiers ».

Playbook de diagnostic rapide

Vous n’avez pas le temps d’admirer le problème. Il faut le localiser : client, réseau, serveur ou identité. Voici un ordre qui minimise les mouvements inutiles.

Premier point : confirmez que c’est le système de fichiers réseau et lequel

• Trouvez le type de montage et les options de montage. Confirmez si des processus sont bloqués sur ce montage.
• Vérifiez si le système connaît une attente I/O généralisée ou seulement un sous-ensemble de threads.

Deuxième point : déterminez si vous êtes bloqué sur I/O, DNS/auth ou stockage serveur

• Pour NFS : recherchez timeouts RPC, « server not responding », retransmissions et stale file handles.
• Pour SMB : recherchez échecs d’auth, tentatives de reconnexion, surcharge signing/chiffrement et problèmes de résolution de noms.

Troisième point : isolez avec une opération contrôlée

• Lisez un petit fichier depuis le partage.
• Faites un stat d’un répertoire avec beaucoup d’entrées (stress métadonnées).
• Créez et fsync un petit fichier (stress des sémantiques d’écriture).

Si les métadonnées sont lentes mais que les lectures vont vite, vous avez probablement des goulots différents de « le réseau est lent ». Si les lectures sont lentes mais les métadonnées correctes, vous saturiez probablement les disques du serveur ou le débit réseau.

Quatrième point : vérifiez les points de saturation

• Client : CPU, softirq et retransmissions TCP.
• Réseau : pertes, erreurs, incompatibilité MTU, congestion.
• Serveur : CPU, NIC, latence disque, pools de threads NFS/SMB, backends d’auth.

Cinquième point : décidez d’une mitigation sûre

• Si c’est un problème temporaire serveur : réduisez la charge cliente, limitez les jobs batch ou basculez si vous avez de la HA.
• Si c’est une option de montage cliente : ajustez-la sur une machine canari, pas sur toute la flotte.
• Si c’est auth/DNS/heure : corrigez la plomberie d’identité avant de toucher au tuning du stockage.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que vous pouvez exécuter sur un client ou serveur Linux. Chacune inclut ce que la sortie signifie et la décision à prendre.

1) Identifier le type de système de fichiers et les options de montage

cr0x@server:~$ findmnt -t nfs,nfs4,cifs -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET   SOURCE                FSTYPE OPTIONS
/mnt/fs  nas01:/export/builds  nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys
/mnt/hr  //files01/hr          cifs   rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,seal,sign,uid=1000,gid=1000

Sens : Vous avez confirmé le protocole en jeu et le mode de panne choisi (p. ex. hard pour NFS). Notez le mode de sécurité (sec=sys vs seal/sign).

Décision : Si les blocages sont le problème et que NFS est monté en hard, traitez les problèmes serveur/réseau comme susceptibles de provoquer des blocs indéfinis. Pour SMB, priorisez les contrôles d’auth/DNS/sécurité.

2) Voir qui est coincé sur le montage (et s’ils sont en état D)

cr0x@server:~$ ps -eo pid,stat,comm,wchan:30,args | egrep ' D |nfs|cifs' | head
24817 D    tar            nfs_wait_on_request          tar -cf /mnt/fs/archive.tar /mnt/fs/work
25002 D    python3        cifs_writepages              python3 ingest.py
 1121 Ss   nfsiod         nfsiod                       [nfsiod]
 1124 Ss   cifsiod        cifsiod                      [cifsiod]

Sens : D signifie sommeil non interruptible, généralement en attente d’I/O. wchan indique quel sous-système bloque (NFS vs CIFS).

Décision : Si de nombreux processus sont en état D, ne « redémarrez pas l’appli » en premier. Vous n’obtiendrez que plus de threads bloqués. Réparez le blocage sous-jacent.

3) Vérifier les logs du noyau pour indices NFS/SMB

cr0x@server:~$ dmesg -T | egrep -i 'nfs:|cifs|smb|server not responding|stale|reconnect|rpc'
[Mon Feb  3 10:14:22 2026] NFS: server nas01 not responding, still trying
[Mon Feb  3 10:14:52 2026] NFS: server nas01 OK
[Mon Feb  3 10:18:06 2026] CIFS: VFS: \\files01 has not responded in 180 seconds. Reconnecting...

Sens : NFS et CIFS enregistrent leurs souffrances. « still trying » est une étiquette d’avertissement : les montages hard attendront. Les reconnexions SMB peuvent bloquer des opérations et amplifier la latence.

Décision : Si vous voyez des « not responding » répétés, orientez-vous vers la santé du réseau/serveur. Si vous voyez des boucles de reconnexion SMB, vérifiez la résolution de noms, l’auth et la disponibilité serveur.

4) Statistiques client NFS : retransmissions et comportement RPC

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1839201    1843       0

Client nfs v4:
null             read             write            commit
0                923114           11822            11822
open             open_conf        close            setattr
224              0                214              19

Sens : Les retransmissions ne sont pas automatiquement mauvaises, mais si elles montent en flèche pendant les incidents, votre goulot est souvent la perte de paquets, la congestion ou un serveur surchargé ne répondant pas à temps.

Décision : Si retrans augmente rapidement, arrêtez de « tuner rsize » et commencez à investiguer les pertes réseau, incompatibilités MTU ou saturation serveur.

5) Vue des exports NFS côté serveur et correspondance client

cr0x@server:~$ showmount -e nas01
Export list for nas01:
/export/builds 10.20.0.0/16
/export/home   10.30.14.0/24

Sens : Confirme que l’export existe et que votre sous-réseau client est autorisé.

Décision : Si un incident débute juste après un déplacement réseau, vérifiez que l’IP du client est toujours dans une plage autorisée. « Ça marchait avant » n’est pas un état de configuration.

6) Vérifier la négociation de version NFS et l’identité du serveur

cr0x@server:~$ rpcinfo -p nas01 | egrep 'nfs|mountd|nlockmgr'
100003    4   tcp   2049  nfs
100003    3   tcp   2049  nfs
100005    3   tcp  20048  mountd
100021    4   tcp  4045   nlockmgr

Sens : Montre quelles versions de protocole sont disponibles. Si vous attendiez v4 seulement mais voyez v3, les clients pourraient utiliser v3 à moins d’être pinnés.

Décision : Épinglez la version explicitement dans les options de montage pour la cohérence, surtout avec des clients mixtes.

7) Vérifier « stale file handle » et décider de remonter

cr0x@server:~$ ls -l /mnt/fs/work
ls: cannot access '/mnt/fs/work': Stale file handle

Sens : Le client a un file handle qui ne mappe plus à l’objet côté serveur. Courant après rollback serveur, revert de snapshot, déplacement d’export ou certains basculements.

Décision : Un remount est généralement nécessaire. Enquêtez aussi sur ce qui a changé côté serveur ; les stale handles sont des symptômes d’actions opérationnelles, pas de rayons cosmiques aléatoires.

8) Visibilité des sessions client SMB (ce que nous avons négocié ?)

cr0x@server:~$ smbstatus -b
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption  Signing
26341   svc-linux    linux         10.20.4.18 (ipv4:10.20.4.18:51234)        SMB3_11           AES-128-GCM required   required

Sens : Confirme le dialecte SMB et si chiffrement/signature sont actifs. Si la performance est mauvaise, cela vous indique si vous payez un coût crypto.

Décision : Si le chiffrement est requis et que le CPU est élevé sur serveur/client, envisagez des serveurs de fichiers dédiés avec AES-NI, ou limitez le chiffrement aux partages sensibles (si la politique le permet).

9) Tester la résolution de nom et le problème du « mauvais serveur »

cr0x@server:~$ getent hosts files01
10.40.2.10  files01.corp.example files01

Sens : Confirme quelle IP votre client utilisera. La dérive DNS peut envoyer des clients vers un nœud retiré, une cible DR ou un load balancer ne gérant pas la permanence SMB.

Décision : Si l’IP est inattendue, corrigez le DNS d’abord. Ne touchez pas aux options de montage pendant que vous parlez au mauvais serveur.

10) Vérifier les retransmissions TCP et erreurs NIC sur le client

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0     120       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7456789      0       0       0      0

Sens : Les pertes peuvent corréler avec les stalls NFS/SMB. Les pertes ne sont pas toujours fatales, mais des pertes persistantes sous charge sont un problème de fiabilité, pas une « opportunité de tuning ».

Décision : Si les pertes augmentent pendant les incidents, examinez les tailles de ring NIC, la congestion sur les switches, softirq CPU et la cohérence MTU bout en bout.

11) Mesurer le MTU du chemin (la fragmentation silencieuse ment)

cr0x@server:~$ ping -M do -s 1472 nas01 -c 2
PING nas01 (10.20.1.50) 1472(1500) bytes of data.
1472 bytes from 10.20.1.50: icmp_seq=1 ttl=63 time=0.621 ms
1472 bytes from 10.20.1.50: icmp_seq=2 ttl=63 time=0.608 ms

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

Sens : Confirme que MTU 1500 fonctionne sans fragmentation. Si des jumbo frames sont impliquées, testez aussi ces tailles.

Décision : Si des payloads plus grands échouent, vous avez peut-être une incompatibilité MTU qui se manifeste comme des « blocages aléatoires sous charge », surtout pour des I/O volumineux.

12) Vérification rapide du débit (test de lecture)

cr0x@server:~$ dd if=/mnt/fs/bigfile.bin of=/dev/null bs=8M count=64 status=progress
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 583 MB/s
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 581 MB/s

Sens : Un test de débit de lecture approximatif. Si ceci est rapide mais que votre appli reste lente, vous avez probablement des problèmes de métadonnées, verrouillage ou petits I/O.

Décision : Ne « réparez pas le stockage » si le chemin de lecture séquentielle est OK. Profilez les métadonnées et les patterns d’accès applicatifs.

13) Test de charge métadonnées (latence d’énumération de répertoire)

cr0x@server:~$ time ls -U /mnt/fs/workdir > /dev/null

real    0m12.418s
user    0m0.012s
sys     0m0.824s

Sens : 12 secondes pour énumérer un répertoire indique un goulot métadonnées : CPU serveur, seeks disque, trop de petits fichiers ou comportement de cache d’attributs.

Décision : Si les métadonnées sont lentes, pensez à réorganiser les charges, utiliser un espace scratch local ou scaler la performance métadonnées du serveur (CPU, RAM, SSD pour métadonnées, meilleur NAS). Tweaker rsize ne vous sauvera pas.

14) Confirmer les options de montage SMB côté client (et si les sémantiques de cache sont saines)

cr0x@server:~$ grep -E 'cifs|smb3' /proc/mounts
//files01/hr /mnt/hr cifs rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,uid=1000,gid=1000,seal,sign,soft,nounix,serverino 0 0

Sens : Vous pouvez voir si vous utilisez cache=strict (souvent plus sûr), le dialecte SMB et les flags de sécurité comme seal (chiffrement).

Décision : Si vous voyez des dialectes anciens ou des modes de cache permissifs, planifiez une mise à jour/serrage. Si le chiffrement est activé et la performance mauvaise, mesurez le CPU et envisagez des changements de politique.

15) Vérifier iowait et softirq CPU (pile réseau sous pression)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  02/03/2026  _x86_64_  (8 CPU)

12:02:11 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:02:12 PM  all   12.3  0.0  8.1   31.7    0.0  9.8    0.0  38.1
12:02:13 PM  all   11.8  0.0  7.9   33.0    0.0  10.2   0.0  37.1

Sens : Un %iowait élevé peut signifier des attentes disque ; un %soft élevé suggère une charge de traitement réseau. Les deux peuvent contribuer aux « blocages ».

Décision : Si softirq est élevé pendant un chiffrement SMB ou un trafic NFS lourd, pensez à scaler le CPU, à ajuster RSS ou le offload NIC—avec précaution et tests.

16) Vérifier la latence disque côté serveur (si vous contrôlez le serveur)

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (nas01)  02/03/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.20   18.10    0.00   63.30

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0   180.0  8800.0  7200.0   2.1   0.4   16.0
sda              15.0    90.0   300.0  1800.0  48.7   2.5   85.0

Sens : await et %util pointent vers la contention disque. Un seul disque saturé peut ruiner la journée de tout le monde s’il héberge métadonnées ou journaux.

Décision : Si un appareil est saturé, corrigez le layout stockage (déplacer métadonnées/journal, ajouter SSD, rééquilibrer, réparer RAID) avant de toucher aux flags de protocole.

Trois mini-récits du monde de l’entreprise

Incident causé par une mauvaise hypothèse : « NFS est sans état donc la bascule est triviale »

Une entreprise de taille moyenne stockait des artefacts de build sur un export NFS soutenu par un système de stockage clusterisé. L’équipe plateforme a supposé que parce que NFSv3 est « sans état », la bascule entre têtes de stockage serait transparente. Ils ont testé une bascule manuelle pendant le déjeuner. Ça avait l’air correct. Ils ont déclaré victoire et sont passés à autre chose.

Des semaines plus tard, une vraie bascule de contrôleur est survenue pendant une release. Les builds ont commencé à se bloquer. Pas échouer—se bloquer. Les agents CI se sont entassés et les temps de file ont explosé. L’astreinte a vu que l’export était toujours monté partout, alors ils ont redémarré les agents. Cela n’a fait qu’engendrer plus d’I/O bloquée.

Le vrai problème : le système de fichiers derrière l’export avait bougé d’une façon qui changeait le mapping des file handles pour certains répertoires. Les clients ont commencé à lancer des erreurs de stale file handle pour certains chemins et des retraits indéfinis pour d’autres. Pire, le système de build utilisait beaucoup de patterns rename-et-stat qui amplifiaient les appels métadonnées. Les clients étaient coincés dans des retraits et de la revalidation.

La correction fut terre-à-terre : standardiser sur NFSv4.1 avec sémantique de session appropriée, activer des file handles stables côté stockage et—surtout—documenter ce que la bascule fait aux montages clients. Ils ont aussi ajouté un job canari qui exerçait des opérations lourdes en métadonnées et alertait si la latence changeait après des basculements.

La leçon : « sans état » ne veut pas dire « immunisé contre les douleurs liées à l’état ». Votre état applicatif existe toujours, votre cache client existe, et le serveur doit toujours mapper des handles à de vrais objets.

Optimisation qui a mal tourné : « Activer le chiffrement SMB partout ; la sécurité sera contente »

Une entreprise globale a décidé d’exiger le chiffrement SMB3 sur tous les partages, y compris ceux utilisés pour la distribution massive de logiciels. L’intention était bonne : des données sensibles existent et ils ne voulaient pas faire confiance à chaque segment réseau pour toujours. Ils ont appliqué la politique côté Windows et mis à jour les configs Samba en conséquence.

En quelques jours, des hôtes Linux montant des partages avec seal ont commencé à rapporter des stalls intermittents durant les heures de pointe. Des copies qui prenaient des minutes prenaient maintenant beaucoup plus longtemps, et les tâches interactives paraissaient « collantes ». Rien n’était en panne. Tout était simplement… assez lent pour qu’on attribue ça au « réseau ».

Ils ont cherché MTU, switches, même les arrays de stockage. L’indice se trouvait sur les serveurs de fichiers : utilisation CPU élevée, spécifiquement dans les chemins liés au crypto, et softirq élevé. Le chiffrement n’ajoutait pas seulement un overhead ; il déplaçait le goulot des disques vers les CPUs. Sous charge, la mise en file d’attente signifiait une latence de tail longue, que les utilisateurs ressentaient comme des blocages.

Le compromis final fut pragmatique : le chiffrement resta requis sur les partages sensibles et optionnel sur les partages de distribution massive confinés à des zones réseau de confiance. Ils ont aussi upgradé les serveurs de fichiers vers des CPUs avec meilleure accélération AES et ajusté SMB multichannel quand pertinent.

La leçon : les fonctions de sécurité ne sont pas gratuites. Si vous ne mesurez pas la marge CPU et la latence tail, vous pouvez « sécuriser » vos partages au point de les rendre inutilisables.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Automount avec timeouts sensés et un canari »

Une équipe fintech utilisait à la fois NFS (home Linux, outillage) et SMB (partages inter-plateformes). Ils avaient été brûlés par des montages bloqués des années plus tôt, alors ils traitaient les systèmes de fichiers réseau comme des dépendances, pas comme des disques locaux.

Ils utilisaient autofs pour les montages utilisateurs et évitaient de monter des partages critiques au boot à moins que le système puisse tolérer un blocage. Ils définissaient aussi explicitement les versions NFS et des timeouts conservateurs, puis testaiennt la disparition du serveur. Le test n’était pas théorique ; ils ont littéralement débranché des chemins en staging.

Quand un événement de maintenance a réellement mis hors service un nœud de stockage, la plupart des services sont restés sains parce qu’ils ne se bloquaient pas au boot ou pendant des opérations sans rapport. L’alerte canari s’est déclenchée : la latence métadonnées sur le partage a franchi un seuil, et l’astreinte pouvait voir « c’est une dépendance stockage » immédiatement.

Ils ont tout de même eu un impact sur les workflows dépendant du partage. Mais l’incident est resté contenu. Pas d’effondrement en cascade. Pas de « redémarrons tout ». Juste une panne de dépendance claire et une remise en service claire.

La leçon : les pratiques ennuyeuses—automount, versions explicites, canaris—ne semblent pas héroïques. Elles évitent les actions héroïques.

Erreurs courantes (symptôme → cause → correction)

1) Symptôme : processus bloqués en état D, kill -9 ne fonctionne pas

Cause : Montage NFS en hard (ou I/O CIFS bloquée) attendant serveur/réseau. Le noyau attend la complétion d’I/O.

Correction : Rétablir la connectivité serveur/réseau. Si vous devez récupérer un hôte, démontez proprement (umount) après résolution de la connectivité, ou utilisez un démontage lazy uniquement en dernier recours et attendez-vous à des conséquences.

2) Symptôme : erreurs « Stale file handle » après maintenance

Cause : Changement côté serveur du filesystem/export (rollback, revert de snapshot, export déplacé, basculement sans handles stables).

Correction : Remonter les clients affectés. Côté serveur, assurez des file handles stables lors de basculements et évitez les rollback sur exports en production sans plan coordonné de remount client.

3) Symptôme : montages SMB se bloquent de façon intermittente, surtout à l’heure pile

Cause : Renouvellement de tickets Kerberos ou dérive d’horloge ; les retries d’auth et reconnections bloquent les opérations.

Correction : Assurez-vous que NTP est correct. Validez la configuration Kerberos et les SPN. Privilégiez Kerberos avec DNS et noms de service corrects, pas des contournements fragiles.

4) Symptôme : excellent débit séquentiel, performances « ls » et « find » catastrophiques

Cause : Goulot métadonnées : trop de petits fichiers, CPU serveur, disques lents pour métadonnées ou cache insuffisant.

Correction : Ré-architectez la charge (regrouper artefacts, utiliser cache local), améliorez la couche métadonnées (SSD), ou scalez CPU/RAM serveur. Le tuning de protocole résout rarement une charge liée aux métadonnées.

5) Symptôme : le partage SMB est lent uniquement quand la politique de sécurité est activée

Cause : Overhead de signature/chiffrement ou inspection de paquets ; le CPU devient le goulot.

Correction : Mesurez le CPU et la latence tail. Utilisez du matériel avec accélération crypto, activez multichannel si pertinent, et segmentez l’exigence de chiffrement selon la sensibilité des données et les zones réseau de confiance.

6) Symptôme : NFS fonctionne depuis certains sous-réseaux mais pas d’autres

Cause : Restrictions d’export, règles de pare-feu ou services RPC bloqués (surtout pour les services de verrouillage NFSv3).

Correction : Préférez NFSv4 (port bien connu 2049) pour réduire la complexité des pare-feu. Alignez les règles d’export avec les sous-réseaux clients réels et documentez-les.

7) Symptôme : accès mixte Linux/Windows provoque des bizarreries « fichier verrouillé »

Cause : Servir le même jeu de données via NFS et SMB avec sémantiques de verrouillage/caching non alignées.

Correction : Évitez le double-protocole sur le même dataset vivant à moins que la plateforme de stockage ne garantisse explicitement la cohérence des verrous entre protocoles et que vous ayez testé vos patterns applicatifs exacts.

8) Symptôme : blocages aléatoires sous charge après « activation des jumbo frames »

Cause : Incompatibilité MTU quelque part sur le chemin ; paquets larges mis en blackhole provoquent retransmissions et stalls.

Correction : Validez le MTU bout en bout. Utilisez ping -M do depuis les clients vers le serveur. Ne déployez pas partiellement les jumbo frames.

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

Checklist de sélection de protocole (choisir NFS ou SMB avec intention)

1. Clients : Majoritairement Linux ? Biais vers NFSv4. Majoritairement Windows/AD ? Biais vers SMB3.
2. Modèle de permissions : Besoin de fidélité ACL NTFS et d’outils Windows ? SMB. Besoin de sémantique POSIX-first ? NFS.
3. Tolérance aux pannes : Bloquer est-il pire qu’échouer ? Considérez les timeouts et le comportement applicatif ; ne supposez pas que les valeurs par défaut sont acceptables.
4. Sécurité : Si vous avez besoin de chiffrement sur le fil, SMB3 le propose en standard. NFS peut faire Kerberos et être tunellé, mais la complexité opérationnelle augmente.
5. Réalité réseau : Les liens instables et réseaux qui clignotent punissent les sémantiques avec état. Préférez la stabilité et instrumentez le chemin.
6. Propriété opérationnelle : Qui va déboguer à 3 h du matin ? Choisissez la pile que votre équipe peut réellement exploiter.

Étapes de durcissement NFS en production

1. Standardisez sur NFSv4.1+ sauf nécessité explicite de v3.
2. Épinglez versions et options de montage pour que le comportement ne dérive pas entre distributions.
3. Utilisez l’automount pour les partages utilisateurs afin d’éviter les blocages au boot et réduire le rayon d’impact.
4. Instrumentez retransmissions et latence (client nfsstat, métriques serveur).
5. Planifiez les basculements : testez le comportement stale handle ; documentez les procédures de remount ; assurez des file handles stables si la plateforme le supporte.
6. Décidez du hard vs soft consciemment : hard pour la correction ; soft seulement si les applis tolèrent les erreurs et que vous acceptez le risque.

Étapes de durcissement SMB en production

1. Exigez SMB3 ; désactivez les dialectes hérités.
2. Décidez de la portée signing/chiffrement et vérifiez la marge CPU sous charge maximale.
3. Corrigez DNS et synchronisation horaire avant d’accuser le stockage.
4. Utilisez Kerberos correctement si vous êtes en AD : SPN, noms de service et hostnames cohérents comptent.
5. Validez les options de montage client (cache=strict, dialecte, flags sécurité) et gardez-les uniformes sur la flotte.
6. Testez le comportement oplocks/leases avec vos applications si vous observez des lectures obsolètes ou des blocages de verrous.

Plan de migration (lorsque vous changez de protocole)

1. Inventoriez les patterns d’accès : séquentiel, intensif en métadonnées, intensif en verrous, éditions cross-platform.
2. Choisissez un groupe canari (quelques hôtes, quelques utilisateurs) et définissez des métriques de succès (latence p95, taux d’erreur, temps de build).
3. Ne faites un double-write que si nécessaire, et si vous le faites, comprenez les risques de cohérence.
4. Basculer par phases, gardez le rollback simple (swap d’alias DNS, changements de mount maps) et documentez le playbook opérationnel.
5. Après coupure, retirez les montages legacy pour ne pas déboguer deux systèmes indéfiniment.

FAQ

1) Lequel « bloque » le plus : NFS ou SMB ?

Les deux peuvent le faire. NFS avec montages hard tend à produire le comportement le plus dramatique « coincé pour toujours » parce que le noyau retentera indéfiniment par conception. Les blocages SMB proviennent souvent d’auth/reconnexion/résolution de noms et peuvent paraître intermittents.

2) Dois-je utiliser un jour des montages soft pour NFS ?

Parfois, mais traitez cela comme manipuler des explosifs : uniquement si l’application est conçue pour gérer correctement les erreurs d’I/O et que vous préférez échouer plutôt que bloquer. Pour beaucoup de charges sensibles à la cohérence ou intensives en écriture, les montages soft peuvent créer de la corruption silencieuse ou des écritures partielles.

3) NFSv4 est-il toujours meilleur que NFSv3 ?

Pour la plupart des environnements modernes, oui—surtout pour la simplicité pare-feu et le verrouillage intégré. Mais l’état ajouté de NFSv4 peut compliquer la récupération sur des réseaux instables. Si vous avez des contraintes legacy, v3 peut rester viable avec une discipline opérationnelle stricte.

4) Pourquoi « ls » sur le partage est-il plus lent que copier un gros fichier ?

Parce que les opérations métadonnées sont de nombreux allers-retours : lookups, stats, vérifications de permissions, revalidation. Les grosses lectures séquentielles amortissent l’overhead. Si votre charge est intensive en métadonnées (arbres de build, checkouts git, millions de petits fichiers), il faut concevoir pour la performance métadonnées.

5) Puis-je servir le même répertoire via NFS et SMB ?

Vous pouvez, mais c’est risqué à moins que la plateforme de stockage ne garantisse explicitement le verrouillage cohérent et la consistance de cache entre protocoles. Testez vos patterns applicatifs exacts. La plupart des bizarreries « aléatoires » cross-protocole sont en fait des divergences sémantiques déterministes.

6) Le chiffrement SMB garantit-il une meilleure sécurité que NFS ?

Le chiffrement SMB3 est simple à déployer et largement utilisé. La sécurité NFS se fait souvent avec Kerberos (bon) ou avec des protections réseau (ce qui peut suffire si vous contrôlez le chemin). Le meilleur choix dépend de votre pile d’identité et du modèle de confiance réseau, pas du fanatisme protocolaire.

7) Quelle est la manière la plus rapide de prouver que le problème vient du réseau ou du disque serveur ?

Regardez les retransmissions client et les pertes NIC, et comparez avec la latence disque serveur. Si les retransmissions montent et que les disques semblent sains, suspectez le réseau. Si les disques affichent await/%util élevés et le réseau est propre, suspectez le stockage. Validez ensuite avec une lecture contrôlée et un test métadonnées.

8) Pourquoi les problèmes SMB coïncident-ils parfois avec des changements de mot de passe ou des mises à jour de politique ?

Parce que SMB en entreprise est fortement couplé à la politique d’identité. La rotation de credentials, les changements de politique Kerberos ou l’inaccessibilité des contrôleurs de domaine peuvent casser des montages ou provoquer des boucles de reconnexion qui se manifestent en stalls.

9) Quel est le « moins pire » choix par défaut pour une nouvelle flotte Linux ?

NFSv4.1+ pour le partage Linux-vers-Linux, avec automount et options de montage explicites. Si votre organisation est AD-first et attend un comportement ACL Windows, choisissez SMB3 et investissez dans la correction d’identité et la marge CPU.

Conclusion : prochaines étapes à réaliser aujourd’hui

Cessez de traiter les systèmes de fichiers réseau comme des disques locaux avec un câble plus long. Choisissez le protocole qui correspond à votre modèle d’identité et au mix de clients, puis concevez le mode de panne que vous pouvez accepter vivre.

1. Sur un client affecté, exécutez findmnt, dmesg et ps pour identifier si vous avez affaire à NFS ou SMB et si vous êtes bloqué en état D.
2. Mesurez les retransmissions et pertes (NFS : nfsstat ; réseau : ip -s link) avant de toucher aux réglages.
3. Exécutez un test de lecture et un test métadonnées pour déterminer si vous êtes lié au débit ou aux métadonnées/verrouillage.
4. Standardisez les configurations : épinglez versions de protocole, options de montage et modes de sécurité sur les hôtes. La dérive est la façon dont le « aléatoire » entre dans vos post-mortems.
5. Rendez les blocages observables : mettez des canaris pour la latence p95/p99 et les taux d’erreur sur les partages. Vous ne pouvez pas gérer ce que vous ne voyez pas, et « les utilisateurs qui se plaignent » ne sont pas du monitoring.

Si vous faites ces cinq choses, le prochain « blocage aléatoire » deviendra une enquête circonscrite au lieu d’une crise existentielle.