Debian 13 : délais NFS — options de montage qui améliorent la stabilité (et quand elles ne le font pas)

décembre 13, 2025 • février 3, 2026 • Lecture : 32 min • Views: 13

Cet article vous a aidé ?

Vos hôtes Debian 13 fonctionnent bien… jusqu’au jour où ils ne fonctionnent plus : un job de build se fige, un nœud web cesse de faire pivoter les logs, ou un nœud Kubernetes semble « up » mais ne peut pas ls un répertoire. Vous vérifiez l’application. Rien.
Vous regardez le CPU. Ennui. Puis vous trouvez le coupable : nfs: server foo not responding, still trying.

Les timeouts NFS donnent l’impression d’une trahison parce qu’ils ne sont rarement une seule chose. Ils résultent d’une négociation entre le client noyau,
le serveur, le réseau et le stockage derrière le serveur. Les options de montage peuvent rendre cette négociation équitable — ou
elles peuvent juste bâillonner le messager pendant que l’incendie se propage. Faisons la première option.

Ce que « timeout NFS » signifie réellement sur Linux

Sur Debian 13, « timeout NFS » est généralement rapporté comme un symptôme côté client : des RPC vers le serveur n’ont pas terminé
dans le délai attendu et le client réessaie (ou abandonne, si vous l’y avez forcé). Le détail clé :
la plupart des « timeouts » ne sont pas un simple minuteur qui expire une fois. Ce sont une série de retransmissions, de backoffs,
et de tentatives de récupération d’état à plusieurs couches.

Le client peut attendre :

Livraison réseau : perte de paquets, incompatibilité MTU, buffers congestionnés, liens instables, bizarreries ECMP.
Traitement RPC côté serveur : threads nfsd saturés, export bloqué sur des E/S disque, délais du gestionnaire de verrous.
Stockage derrière le serveur : reconstruction RAID, pool thin-provisioned plein, SSD surchargé, ARC mal dimensionné, snapshots pathologiques.
Récupération d’état : renouvellement de lease NFSv4, rappels de délégations, changement d’ID client après reboot, périodes de grâce.

Les clients NFS sous Linux peuvent aussi sembler « bloqués » tout en se comportant conformément au design. Un montage hard va continuer à réessayer les E/S
indéfiniment (ou pendant très longtemps) parce que la cohérence prime sur l’échec rapide. Ce n’est pas un problème de timeout ;
c’est la sémantique que vous avez choisie qui se manifeste.

Les questions importantes :

Le client réessaie parce que le serveur est lent, ou parce que le réseau perd des paquets ?
Le client est-il bloqué en sommeil non interruptible (D) sur des appels NFS ?
Le serveur est-il vivant mais le stockage de support est-il bloqué ?
Avez-vous choisi des sémantiques de montage qui correspondent à la tolérance du workload pour la corruption vs le temps d’indisponibilité ?

Une idée paraphrasée de Werner Vogels (CTO d’Amazon) : Tout échoue ; concevez pour que l’échec soit routinier et récupérable.

Faits intéressants et contexte historique

NFS précède le « cloud » de plusieurs décennies : NFS est apparu au milieu des années 1980, conçu pour des LANs où « rapide » voulait dire 10 Mbps et un serveur beige.
NFSv3 est volontairement « quasi sans état » : le serveur ne conserve pas l’état par client des fichiers ouverts comme SMB ; cela réduit la complexité serveur mais transfère la difficulté vers le verrouillage et les retransmissions côté client.
NFSv4 a intégré le verrouillage : NLM/lockd était séparé en v2/v3 ; la v4 a intégré le verrouillage et ajouté un protocole avec état et lease.
Le tuning des timeouts existe à cause du RPC sur UDP : les premières versions de NFS reposaient fortement sur UDP ; le comportement de retransmission était crucial. TCP a amélioré le transport mais n’a pas éliminé les blocages serveurs.
« Stale file handle » est une fonctionnalité, pas un bug : les filehandles NFS encodent l’identité côté serveur ; si l’inode a disparu ou que l’export a été déplacé, le client ne peut pas prétendre que c’est le même fichier.
Les guerres rsize/wsize ont été réelles : sur les anciens réseaux et NICs, on pouvait ruiner les performances avec de mauvaises tailles ; les valeurs par défaut modernes sont plus sensées mais les jumbo/overlays peuvent encore poser problème.
nconnect est relativement récent : plusieurs connexions TCP par montage améliorent le parallélisme ; excellent pour des clients chargés, mais cela peut amplifier la charge sur des serveurs fragiles.
Les timeouts NFS incriminent souvent la mauvaise couche : un array de stockage effectuant un basculement de contrôleur ressemble exactement à du « jitter réseau » du point de vue du client.

Méthode de diagnostic rapide (premier/deuxième/troisième)

Quand on dit « NFS se met en timeout », le bon réflexe est d’arrêter de débattre des flags de montage et de commencer à restreindre le goulot d’étranglement.
Voici l’ordre qui apporte des réponses rapidement sans tout embrouiller.

Premier : confirmer le mode de défaillance sur le client (bloque-t-il ? réessaie-t-il ? échoue-t-il rapidement ?)

Consultez les logs du noyau pour les messages « not responding » et les transitions « OK ».
Vérifiez si des processus sont bloqués en état D sur des appels système NFS.
Examinez les statistiques RPC client NFS : pics de retrans vs trafic normal.

Second : isoler réseau vs CPU serveur vs stockage serveur

Ping ne suffit pas ; vérifiez la perte de paquets, les problèmes de MTU et les retransmissions TCP.
Côté serveur, vérifiez la saturation des threads nfsd et la charge système avec l’attente I/O.
Côté serveur, examinez la latence du système de fichiers de support (par ex. iostat) et cherchez des périphériques bloqués.

Troisième : décider si les options de montage sont une mitigation ou un camouflage

Servez-vous des options de montage pour aligner les sémantiques (hard vs soft, intr, timeo/retrans) sur les besoins du workload.
Ne « réparez » pas des blocages de stockage avec soft à moins d’accepter des écritures partielles et un risque de corruption applicative.
Préférez des options qui améliorent la récupération et réduisent les comportements pathologiques : bg, nofail, timeo raisonnable, version de protocole appropriée, et ordonnancement systemd.

Options de montage qui aident la stabilité (et pièges)

La stabilité en NFS n’est pas juste « ne pas expirer ». C’est « quand quelque chose est lent ou tombe en panne, échouer d’une manière que le système peut
encaisser ». Cela signifie des valeurs par défaut pertinentes pour un usage général, et des exceptions ciblées pour des workloads qui peuvent les tolérer.

Hard vs soft : choisissez des sémantiques, pas des impressions

hard signifie que le client réessaie l’E/S jusqu’à réussite. C’est pourquoi vous voyez « still trying ».
C’est le bon choix pour l’intégrité des données et la plupart des workloads de type POSIX. Cela peut aussi bloquer vos threads applicatifs
si le serveur disparaît. C’est le prix à payer.

soft signifie que le client abandonne après des retransmissions et retourne une erreur à l’application.
Cela paraît « stable » jusqu’à ce que vous réalisiez : certaines applications considèrent les erreurs d’E/S comme transitoires et continuent, possiblement après
écritures partielles ou lectures tronquées inattendues. Vous n’avez pas rendu NFS plus fiable ; vous avez rendu l’échec plus rapide et plus créatif.

Conseils d’opinion :

Utilisez hard pour tout ce qui écrit des données importantes : bases de données, files de messages, magasins d’artefacts, répertoires personnels.
Envisagez soft uniquement pour du contenu majoritairement en lecture, cacheable, non critique et traité correctement par l’application (ex. ferme de rendu qui peut refetcher).
Si vous choisissez soft, formalisez les attentes avec les propriétaires d’applications par écrit. Vous changez la sémantique, pas seulement le tuning.

Blague #1 : Un montage soft, c’est comme une règle de firewall « temporaire » — tout le monde l’oublie, jusqu’au rapport d’incident qui cherche un coupable.

`timeo` et `retrans` : ce qu’ils contrôlent vraiment

Sur NFS Linux, timeo n’est pas « le temps avant l’échec ». C’est le timeout de base RPC avant retransmission, en dixièmes de seconde
pour beaucoup de configurations (couramment : timeo=600 signifie 60 secondes). Le délai effectif peut être bien plus long à cause du backoff exponentiel et des retransmissions.

retrans indique combien de fois réessayer un RPC avant que le client n’escalade son comportement (et pour les montages soft, avant de renvoyer une erreur).
Baisser timeo peut permettre au client de détecter les problèmes plus vite, mais peut aussi augmenter la charge en période de congestion à cause de retransmissions plus fréquentes.
Augmenter timeo peut réduire les tempêtes de retrans sur des liens instables, mais rend les vraies coupures plus longues à ressentir.

Conseils pratiques :

Pour des LAN stables, les valeurs par défaut conviennent souvent. Ne touchez qu’avec des preuves : pics de retrans, liens WAN connus, ou blocages serveurs avérés.
Pour des liens WAN ou bruités, un timeo légèrement supérieur peut réduire le thrash ; ne le portez pas à plusieurs minutes sauf si vous aimez voir des reboot désespérés.
Si vous observez de courtes pauses (quelques secondes) dues à des basculements serveur, ne réagissez pas en mettant des timeo ridiculement petits ; laissez la récupération se produire.

`proto=tcp` et versions NFS : choisissez le protocole que vous pouvez supporter

Sur Debian moderne, vous devriez utiliser TCP. UDP est surtout un vestige de musée sauf si vous travaillez autour d’un cas vraiment étrange.
TCP apporte un comportement meilleur en cas de perte et gère les charges utiles plus grandes de façon plus sensée.

Choix de version :

NFSv4.x (incluant 4.1/4.2) est typiquement le meilleur choix par défaut : moins de ports à gérer, verrouillage intégré, meilleure gestion firewall.
NFSv3 peut encore être approprié pour des serveurs legacy, certains NAS ou cas particuliers. Mais il nécessite plus de composants (rpcbind, mountd, comportement lockd/statd).

Angle stabilité : la récupération d’état en v4 peut être douloureuse lors de reboot serveur (périodes de grâce), mais c’est plus prévisible quand c’est bien configuré.
La v3 peut sembler « plus simple » jusqu’à ce que vous déboguiez la récupération de verrous à 2 h du matin.

`vers=4.1` ou `vers=4.2` vs « négociation automatique »

Laisser client et serveur négocier la version peut convenir, mais c’est aussi la manière dont vous vous retrouvez avec des rétrogradations surprenantes après un changement.
En production, épinglez la version sauf si vous avez une bonne raison de ne pas le faire.

Épinglez vers=4.1 si votre serveur est fiable en 4.1 et que vous n’avez pas besoin des fonctionnalités 4.2.
Utilisez vers=4.2 si les deux côtés le supportent et que vous avez testé. Certaines fonctions 4.2 (copie/clone côté serveur dans certains stacks) sont excellentes ; des implémentations boguées ne le sont pas.

`actimeo` et cache d’attributs : stabilité vs exactitude

actimeo (et les options plus fines acregmin/acregmax/acdirmin/acdirmax) contrôlent le cache d’attributs.
Augmenter les durées de cache réduit les RPCs métadonnées, ce qui peut aider sous charge et réduire l’exposition à des lenteurs transitoires.
Cela peut aussi faire voir des métadonnées obsolètes plus longtemps, ce qui casse les applications qui attendent une cohérence proche close-open.

Cas d’usage :

Fermes de build et CI lisant des dépendances partagées : un cache d’attributs plus grand peut être bénéfique.
Répertoires personnels partagés avec des éditions fréquentes depuis plusieurs hôtes : ne vous amusez pas ; maintenez des valeurs par défaut ou conservatrices.

`rsize`/`wsize` : ne visez pas les benchmarks, visez la latence de queue

Des tailles I/O plus grandes peuvent améliorer le débit mais aggraver la latence tail si le serveur ou le réseau a du mal avec de grosses rafales.
Les valeurs par défaut modernes sont généralement bonnes. Si vous touchez, faites-le avec mesures et plan de retour arrière.

Un pattern courant de stabilité : réduire légèrement wsize quand un serveur fragile tombe sous de fortes rafales d’écriture.
Mais si vous en êtes là, vous traitez le symptôme ; la vraie correction est la capacité serveur/stockage.

`nconnect` : plus de parallélisme, plus de façons de surcharger un serveur

nconnect=N ouvre plusieurs connexions TCP par montage. Cela peut aider énormément sur des clients chargés avec I/O parallèle,
surtout quand un seul flux TCP devient le goulot.

Compromis de stabilité :

Sur des serveurs robustes, cela peut réduire les timeouts en améliorant le débit et en réduisant le queueing.
Sur des serveurs marginaux, cela peut amplifier la charge et rendre les blocages plus fréquents.

Recommandation : commencez par nconnect=4 pour des clients à haut débit si la capacité serveur est connue ; surveillez CPU serveur, threads nfsd et latence.

`noatime` : petit gain, parfois réel

Désactiver les mises à jour atime réduit le trafic d’écriture pour des workloads majoritairement en lecture. Cela ne réparera pas des timeouts causés par des blocages serveur,
mais cela peut gratter un peu de churn de fond et améliorer la stabilité sous charge limite.

Options de stabilité au démarrage : `nofail`, `bg` et timeouts systemd

Beaucoup d’incidents « timeout NFS » commencent par « un hôte ne démarre pas parce que NFS n’est pas prêt ». Ce n’est pas un problème de perf NFS.
C’est de l’ordonnancement de démarrage et de la gestion des échecs.

nofail laisse le démarrage continuer si le montage n’est pas disponible. Idéal pour les montages non critiques ; dangereux pour les montages requis.
bg (principalement pour le comportement NFSv3) met en arrière-plan les tentatives de montage après un essai initial, laissant le boot se poursuivre.
x-systemd.automount crée un automount à la demande ; le système peut démarrer et ne monter que lorsqu’on y accède. C’est une arme de stabilité quand c’est utilisé prudemment.
x-systemd.mount-timeout= contrôle combien de temps systemd attend pour l’unité de montage. Vous pouvez éviter des minutes de blocage au boot.

Verrouillage et « interruptibilité » : sachez ce à quoi vous vous engagez

L’ancienne pratique incluait intr pour interrompre les opérations NFS par signaux. Les noyaux modernes ont changé le comportement ; pour beaucoup de configurations c’est soit par défaut soit sans effet.
Le point reste : tuer un processus bloqué en E/S NFS n’est pas toujours possible, car le noyau attend la réponse du serveur.

Si vous avez besoin que « kill fonctionne toujours », NFS n’est pas la bonne sémantique. Il vous faut une autre architecture : buffering local, réplication asynchrone, ou un store d’objets.

Blague #2 : Ajuster les timeouts NFS sans mesurer le serveur, c’est comme réparer un ascenseur lent en changeant l’autocollant du bouton « fermer la porte ».

Spécificités Debian 13 : systemd, noyau, valeurs par défaut

Debian 13 est livré avec un noyau moderne et un comportement systemd qui fait que les montages NFS se ressentent différemment que l’époque « éditez fstab, reboot, priez ».
Changements opérationnels pertinents :

systemd traite les montages comme des unités avec dépendances ; l’ordre vis-à-vis de network-online.target compte pour les montages distants.
remote-fs.target peut bloquer des services si des montages sont « requis ». Décidez explicitement ce qui doit bloquer et ce qui ne doit pas.
Les utilitaires clients NFS sont séparés : le noyau fournit le client ; les outils userland aident au diagnostic et à la configuration. Assurez-vous d’avoir nfs-common sur les clients.

Mon basique opinionné pour un montage client de production « normal » sous Debian 13 (NFSv4.1 sur LAN) ressemble à :

cr0x@server:~$ cat /etc/fstab
nfs01:/export/shared  /mnt/shared  nfs  vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,_netdev,x-systemd.automount,x-systemd.idle-timeout=60  0  0

Pourquoi ce mélange ?

hard garde les sémantiques de données cohérentes.
timeo=600,retrans=2 est conservateur (pas minuscule) et évite de frapper pendant des blips ; ajustez uniquement avec des preuves.
x-systemd.automount évite les situations où le boot est pris en otage pour beaucoup de workloads.
x-systemd.idle-timeout=60 permet à l’automount de se mettre en idle ; cela peut réduire l’état obsolète sur des portables ou nœuds éphémères.
_netdev signale « dépend du réseau » pour l’ordonnancement.

Quand ce baseline est inadapté :

Si le montage doit être disponible avant le démarrage des services critiques (ex. binaires d’app résident là), l’automount peut créer une latence surprenante au premier accès. Mieux vaut monter tôt et échouer vite, ou repenser l’architecture.
Si vous êtes sur un WAN à haute latence, vous devrez peut-être augmenter timeo et choisir le cache avec soin.
Si votre serveur effectue des basculements planifiés, testez le comportement de récupération sous charge ; les flags de montage ne vous sauveront pas d’un contrôleur de stockage qui pause 45 secondes.

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

Ci‑dessous des tâches opérationnelles que je lancerais réellement. Chacune inclut ce qu’il faut rechercher et la décision qu’elle entraîne.
Exécutez-les d’abord sur un client, puis sur le serveur. Vous construisez une chronologie et isolez la couche fautive.

Tâche 1 : Confirmer ce qui est monté et avec quelles options

cr0x@server:~$ findmnt -t nfs,nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET       SOURCE              FSTYPE OPTIONS
/mnt/shared  nfs01:/export/shared nfs4  rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.2.15,local_lock=none

Ce que ça signifie : vous utilisez NFSv4.1 sur TCP avec un montage hard ; le client va réessayer. rsize/wsize montrent les valeurs négociées.

Décision : si vous voyez vers=3, udp ou l’absence de hard inattendue, corrigez la définition de montage avant de chasser des fantômes.

Tâche 2 : Surveiller les logs noyau pour les basculements “not responding” et “OK”

cr0x@server:~$ sudo journalctl -k -g 'nfs' -S -2h
Dec 29 09:12:41 client01 kernel: nfs: server nfs01 not responding, still trying
Dec 29 09:13:10 client01 kernel: nfs: server nfs01 OK
Dec 29 09:27:02 client01 kernel: nfs: server nfs01 not responding, still trying

Ce que ça signifie : vous avez des blocages intermittents, pas une panne nette. La ligne « OK » suggère que la récupération a lieu.

Décision : des blocages intermittents vous orientent vers l’investigation de la latence serveur/stockage et de la perte réseau, pas vers le DNS ou les fautes dans fstab.

Tâche 3 : Vérifier la présence de processus bloqués en sommeil non interruptible (état D)

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2=="D"{print}' | head
21453 D  tar          nfs_wait_on_request      tar -cf /mnt/shared/backup.tar /var/lib/app
30112 D  rsync        rpc_wait_bit_killable    rsync -a /data/ /mnt/shared/data/

Ce que ça signifie : des processus utilisateur sont bloqués en attente de NFS/RPC. Les tuer peut ne pas fonctionner tant que l’I/O noyau n’est pas terminée ou timeoutée selon les sémantiques.

Décision : si beaucoup de processus sont en D, traitez cela comme un incident d’infrastructure, pas comme un bug applicatif. Poursuivez avec les stats RPC et les vérifications serveur.

Tâche 4 : Inspecter les stats RPC client NFS pour les retransmissions

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
128904     8421       0

Client nfs v4:
null         read         write        commit       open         open_conf
0            48210        19342        0            188          0

Ce que ça signifie : retrans est élevé par rapport aux calls (ici ~6,5%). Cela signifie généralement perte de paquets, congestion ou blocages serveur suffisamment longs pour déclencher des retries.

Décision : si retrans est proche de zéro, le problème peut être un blocage côté application ou serveur sans perte de paquets (toujours possible). Si retrans est élevé, priorisez la réactivité du réseau et du serveur.

Tâche 5 : Confirmer la connectivité de base et détecter la perte (pas seulement la latence)

cr0x@server:~$ ping -c 50 -i 0.2 nfs01
PING nfs01 (10.10.2.20) 56(84) bytes of data.
64 bytes from 10.10.2.20: icmp_seq=1 ttl=64 time=0.424 ms
64 bytes from 10.10.2.20: icmp_seq=2 ttl=64 time=0.391 ms
...
--- nfs01 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 10047ms
rtt min/avg/max/mdev = 0.320/0.410/0.690/0.072 ms

Ce que ça signifie : pas de perte ICMP évidente ; bon signe, pas une preuve. ICMP peut être priorisé différemment du trafic NFS.

Décision : s’il y a de la perte ici, vous avez un incident réseau. Si non, poursuivez avec TCP et les compteurs d’interface.

Tâche 6 : Vérifier les compteurs d’interface pour drops et erreurs sur le client

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      912345678  854321      0    412       0   12345
    TX:  bytes packets errors dropped carrier collsns
      812345001  743210      0      0       0       0

Ce que ça signifie : des RX drops indiquent congestion, overflow de ring buffer, ou problèmes en amont. Les drops sont fortement corrélés aux retrans RPC.

Décision : si les drops augmentent pendant les incidents, investiguez les réglages offload NIC, la charge hôte, la congestion du switch et le MTU. Ne touchez pas aux timeouts NFS tout de suite.

Tâche 7 : Vérifier la cohérence MTU et chercher des indices de fragmentation

cr0x@server:~$ ip link show dev eth0 | grep -E 'mtu|state'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

Ce que ça signifie : MTU est 1500. Si votre réseau utilise des jumbo frames de manière inconsistante, vous pouvez avoir des problèmes PMTU qui ressemblent à des « stalls NFS aléatoires ».

Décision : si vous suspectez une incompatibilité MTU, standardisez temporairement à 1500 de bout en bout ou assurez la cohérence des jumbo (hôtes, switches, bonds, VLANs, overlays).

Tâche 8 : Vérifier les retransmissions TCP sur le client

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpTimeouts'
TcpRetransSegs                 1932
TcpTimeouts                    41

Ce que ça signifie : des retrans TCP et timeouts suggèrent perte réseau ou congestion sévère — pas uniquement un problème serveur NFS.

Décision : si ces compteurs grimpent pendant les incidents, concentrez-vous sur le chemin réseau et les files NIC hôte. S’ils restent stables, concentrez-vous plutôt sur la latence serveur/stockage.

Tâche 9 : Confirmer que le serveur est joignable sur les ports NFS attendus et le protocole

cr0x@server:~$ sudo ss -tn dst 10.10.2.20 | head
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port  Process
ESTAB  0      0      10.10.2.15:51144    10.10.2.20:2049
ESTAB  0      0      10.10.2.15:51146    10.10.2.20:2049

Ce que ça signifie : connexions TCP actives vers le port 2049 (NFS). Si vous attendiez NFSv4 et voyez un bazar de ports auxiliaires, vous êtes peut-être en v3.

Décision : si les connexions fluctuent ou si Recv-Q grossit, vous avez peut-être une lenteur côté serveur ou un queueing réseau. Passez aux métriques serveur.

Tâche 10 : Côté serveur, vérifier la saturation des threads nfsd et la santé basique

cr0x@server:~$ sudo cat /proc/net/rpc/nfsd | head -n 20
rc 0 0 0
fh 0 0 0 0 0
io 123456 654321
th 64 0 0.000 0.000 0.000 0.000 0 0 0 0
ra 32 0 0 0 0 0 0 0 0 0 0 0
net 0 0 0 0
rpc 1234 0 0 0 0 0 0 0 0 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc4 2 0 0

Ce que ça signifie : la ligne th montre le nombre de threads nfsd (ici 64). Si ce nombre est petit sur un serveur occupé, vous pouvez avoir du queueing.

Décision : si les threads nfsd sont trop peu nombreux, augmentez-les de façon appropriée (et assurez-vous que le CPU est disponible). Si les threads sont nombreux mais que les stalls persistent, regardez la latence du stockage de support.

Tâche 11 : Côté serveur, repérer rapidement l’attente I/O et le stockage bloqué

cr0x@server:~$ sudo iostat -xz 1 5
Linux 6.10.0 (nfs01)  12/29/2025  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.20   38.50    0.00   45.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         210.0  16800.0     0.0   0.00    8.20    80.0     95.0   9200.0     0.0   0.00   62.30    96.8    7.10   92.0

Ce que ça signifie : un %iowait élevé plus un w_await élevé et un %util élevé suggèrent une saturation ou une latence du stockage.

Décision : si le stockage de support est le goulot, les options de montage ne le guériront pas. Vous avez besoin de capacité stockage, cache, réglage de files ou shaping des workloads.

Tâche 12 : Confirmer les exports et l’accès par client sur le serveur

cr0x@server:~$ sudo exportfs -v
/export/shared  10.10.2.0/24(rw,wdelay,root_squash,sec=sys,async,no_subtree_check,fsid=0)
/export/backups 10.10.2.15(rw,root_squash,sec=sys,sync,no_subtree_check)

Ce que ça signifie : affiche les options d’export. Notez la différence entre async et sync, et la portée par client/sous-réseau.

Décision : si vous voyez par accident sync sur un export chargé (ou l’inverse), vous avez trouvé un levier stabilité/perf — manipulez-le prudemment et testez. Vérifiez aussi que les bons clients sont autorisés ; des refus d’accès peuvent ressembler à des timeouts côté app.

Tâche 13 : Vérifier les logs serveur NFS pour périodes de grâce et événements de récupération

cr0x@server:~$ sudo journalctl -u nfs-server -S -2h | tail -n 30
Dec 29 09:11:58 nfs01 systemd[1]: Starting NFS server and services...
Dec 29 09:11:58 nfs01 kernel: NFSD: starting 64-second grace period (net ffffffff9a6a0000)
Dec 29 09:12:02 nfs01 systemd[1]: Started NFS server and services.

Ce que ça signifie : les périodes de grâce affectent les clients NFSv4 qui réclament des verrous. Pendant la grâce, certaines opérations peuvent se bloquer ou échouer de manière spécifique.

Décision : si les timeouts s’agglomèrent autour de redémarrages/bascules serveur, concevez pour la grâce/récupération : retries applicatives, fenêtres de maintenance, ou HA qui préserve correctement l’état.

Tâche 14 : Valider le mapping de noms et le mapping d’ID (douleur NFSv4 qui ressemble à un « hang »)

cr0x@server:~$ nfsidmap -c
cr0x@server:~$ nfsidmap -l | head
0x00000001: user@domain
0x00000002: nobody@domain

Ce que ça signifie : les caches idmap peuvent devenir obsolètes ou mal configurés, causant des anomalies de permissions perçues comme « NFS cassé ».

Décision : si les utilisateurs voient des « permission denied » ou des propriétaires étranges sur des chemins montés, vérifiez l’idmapping et la stratégie UID/GID cohérente avant de toucher aux timeouts.

Tâche 15 : Tester la latence perçue avec une boucle I/O contrôlée

cr0x@server:~$ time bash -c 'for i in {1..200}; do echo $i > /mnt/shared/.lat_test.$i; done'
real    0m2.913s
user    0m0.059s
sys     0m0.351s

Ce que ça signifie : rapide test de sanity pour de petites écritures synchrones. Répétez pendant un incident ; si real explose, vous voyez la latence du stockage ou du traitement serveur.

Décision : si de petites écritures deviennent secondes-à-minutes, le tuning de montage ne résoudra pas. Investiguer disques serveur, options d’export (sync/async) et charge serveur.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : Incident causé par une fausse hypothèse (« les montages hard sont le problème »)

Une entreprise de taille moyenne avait des clients Debian montant un export NFS partagé pour des artefacts CI. Les builds ont commencé à se « figer » aléatoirement.
L’équipe plateforme a remarqué des processus en D et a conclu que le montage était le problème. Ils ont passé le montage en soft,timeo=50,retrans=2.

Les blocages ont cessé. Les tickets se sont calmés. Tout le monde a félicité le « correctif de stabilité ». Deux semaines plus tard, l’ingénierie release a trouvé des artefacts corrompus :
des tarballs qui se décompressaient avec des fichiers manquants, des checksums non concordants, et quelques builds « réussis » mais non reproductibles.
Les logs montraient des EIO occasionnels sur des appels write que les outils de build n’ont pas traités comme fatals parce qu’ils n’étaient pas conçus pour un stockage non fiable.

La cause sous-jacente était un array de stockage derrière le serveur NFS réalisant des pics de latence périodiques pendant le nettoyage de snapshots.
Le serveur n’était pas « down », il était simplement parfois incapable de servir les RPC à temps, si bien que les clients retransmettaient, puis — sous soft — abandonnaient.

Ils sont revenus à hard, puis ont corrigé le vrai coupable : la planification des snapshots et la marge de performance de l’array.
Ils ont aussi ajouté une vérification des artefacts et fait de « les erreurs I/O sont fatales » une politique explicite dans la CI.
La leçon durable n’était pas « jamais utiliser soft ». C’était « ne traitez pas les sémantiques comme de simples réglages ».

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (cache agressif et jumbo frames)

Une autre organisation disposait d’un serveur NFS rapide et voulait réduire la charge métadonnées. Quelqu’un a réglé le cache d’attributs :
actimeo=60 sur une flotte, plus des rsize/wsize plus grands, plus activation des jumbo frames sur de nouveaux hôtes.
Le débit semblait excellent dans des tests synthétiques. Moins de RPCs, plus de MB/s. Des slides ont été faits. Des promotions presque assurées.

Puis un sous-ensemble de clients a commencé à voir des hangs mystérieux et des « server not responding » pendant les heures de pointe.
Pas tous les clients. Pas tout le temps. Le genre de problème qui transforme des ingénieurs confiants en astrologues amateurs.

Le problème était une incohérence MTU sur quelques ports de switch dans une paire de leafs.
Certains chemins supportaient les jumbo frames, d’autres laissaient tomber silencieusement les paquets trop grands. La découverte PMTU TCP ne se rétablissait pas de façon fiable à cause d’ICMP « fragmentation needed » filtrés par un segment de firewall qui « n’était pas censé être dans le chemin ».

Les réglages de cache ont d’abord masqué le problème (moins d’appels métadonnées), mais les I/O plus larges combinées aux jumbo ont rendu le trou noir plus pénalisant.
Corriger la cohérence MTU et autoriser les ICMP pertinents a restauré la stabilité. Ils ont conservé un cache modéré, mais ont arrêté de considérer le réseau comme un dorsale infaillible.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la journée (automount + ordonnancement explicite)

Une entreprise proche de la finance avait pour habitude : chaque montage NFS dans fstab utilisait _netdev,x-systemd.automount,x-systemd.mount-timeout=15,
et les montages « critiques » étaient gérés par une unité dédiée qui nécessitait network-online.target plus un health check.
Ce n’était pas glamour. Ça n’améliorait pas les benchmarks. C’était essentiellement de la supervision adulte pour le démarrage.

Un jour, un switch cœur a redémarré inopinément. La moitié de la flotte a perdu le réseau pendant quelques minutes.
Les services dramatiques ont flanché ; les services ennuyeux ont récupéré. Important : les hôtes ne sont pas restés bloqués au démarrage et n’ont pas bloqué des services non liés.
Quand le serveur NFS est redevenu joignable, l’automount a rétabli les montages à la demande.

Ils ont toujours eu des erreurs applicatives (à cause de la coupure réseau), mais ils n’ont pas eu une catastrophe de second ordre : boots bloqués, déploiements bloqués,
et reboots paniqués ralentissant la récupération. Le postmortem contenait une ligne rare : « La configuration des montages s’est comportée comme prévu. »

La pratique n’était pas brillante. Elle était correcte. En production, « correct » vieillit mieux que « brillant ».

Erreurs courantes : symptôme → cause racine → correction

1) Spam « server not responding », mais le ping est ok

Symptôme : logs noyau montrent NFS not responding ; ping ICMP ne montre pas de perte.

Cause racine : blocages du stockage serveur ou saturation nfsd ; ICMP ne reflète pas la latence RPC applicative.

Correction : vérifiez iostat serveur pour await/util élevés ; vérifiez les threads nfsd ; corrigez la marge de performance du stockage. Ne touchez pas timeo les yeux fermés.

2) Démarrage bloqué indéfiniment en attente de NFS

Symptôme : nœud rebooté reste sur « A start job is running for /mnt/shared ».

Cause racine : montage requis sans ordonnancement/timeout systemd adéquat ; réseau pas « online » encore, ou serveur NFS indisponible.

Correction : utilisez _netdev, x-systemd.automount et x-systemd.mount-timeout=. Pour les montages réellement requis, gatez les services dépendants et échouez vite.

3) « permission denied » aléatoire après un montage propre

Symptôme : montage réussi ; utilisateurs voient mauvaises ownerships ou accès refusés ; on appelle ça « NFS flaky ».

Cause racine : mismatch idmapping NFSv4 (domaine), UID/GID incohérents, cache idmap obsolète.

Correction : standardisez l’identité (LDAP/SSSD ou IDs locaux cohérents), configurez le domaine idmap, videz les caches via nfsidmap -c.

4) Processus client bloqués en D-state pendant des heures

Symptôme : processus innukables ; système « up » mais inutilisable.

Cause racine : sémantique hard + serveur unreachable ou I/O bloquée ; parfois aggravé par un trou noir réseau.

Correction : restaurez serveur/réseau. Si c’est inacceptable opérationnellement, repensez : buffering local, pipelines asynchrones, ou séparez les chemins critiques de NFS.

5) « Stale file handle » après maintenance ou changements d’export

Symptôme : applications échouent sur des chemins existants ; nouveaux montages fonctionnent.

Cause racine : objets système de fichiers modifiés/déplacés côté serveur ; export remappé ; FS recréé ; snapshots restaurés.

Correction : remontez les clients ; évitez de changer l’identité de la racine d’export ; utilisez des exports stables ; documentez les étapes de maintenance qui invalident les handles.

6) Basculer en `soft` « règle » les timeouts mais cause des corruptions silencieuses

Symptôme : moins de blocages ; plus tard des fichiers corrompus ou sorties incomplètes sans erreurs claires.

Cause racine : le montage soft renvoie des erreurs en plein milieu d’opérations ; l’application ne les traite pas comme fatales ; des résultats partiels persistent.

Correction : revenez à hard pour les écritures ; ajoutez des vérifications d’intégrité de bout en bout ; corrigez le serveur/réseau causant les retransmissions.

7) nconnect améliore le débit, puis les timeouts empirent

Symptôme : débit plus élevé en tests ; en production sous charge, le serveur devient moins réactif ; des timeouts apparaissent.

Cause racine : augmentation du parallélisme amplifie la charge CPU serveur, nfsd, ou stockage ; le queueing augmente la latence tail.

Correction : réduisez nconnect, augmentez la capacité serveur, ou isolez les workloads ; mesurez la latence et la saturation de threads côté serveur.

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

Checklist A : stabiliser d’abord, puis tuner

Confirmez les sémantiques de montage : gardez hard pour tout ce qui écrit des données importantes.
Prévenir les scénarios de prise en otage au boot : ajoutez _netdev,x-systemd.automount,x-systemd.mount-timeout=15 pour les montages non critiques.
Épinglez protocole/version : choisissez vers=4.1 ou vers=4.2 délibérément ; imposez proto=tcp.
Mesurez les retrans : utilisez nfsstat -c et nstat avant de changer timeo.
Corrigez la couche lente : perte réseau, saturation CPU serveur, ou latence stockage. Les options de montage ne sont pas de la puissance brute.

Checklist B : décisions d’options de montage selon le workload

Bases de données sur NFS : évitez si possible ; si imposé, utilisez hard, cache conservateur, validez les garanties serveur, et testez le comportement de bascule.
Répertoires personnels : hard, valeurs par défaut pour le cache, concentrez-vous sur HA serveur et stabilité réseau.
Dépendances partagées majoritairement en lecture : envisagez des tweaks de cache d’attributs ; pensez à x-systemd.automount pour éviter les problèmes au boot.
Nœuds de calcul éphémères : automount avec idle timeout réduit l’état obsolète de longue durée et rend les reboots moins dramatiques.
Liens WAN : acceptez une latence plus élevée ; montez timeo modestement ; considérez des couches de cache locales plutôt que de prétendre que le WAN est un LAN.

Étapes : un plan de changement sensé pour les options de montage

Choisissez un client canari. Ne déployez pas directement à toute la flotte pour apprendre.
Documentez le baseline : findmnt, nfsstat -c, nstat, et un petit test I/O en boucle.
Changez une seule dimension (ex. épinglez vers=4.1, ou ajoutez x-systemd.automount).
Re-testez sous charge ; surveillez iostat serveur et les stats nfsd.
Déployez progressivement. Gardez les instructions de rollback dans le ticket, pas dans la mémoire de quelqu’un.

FAQ

1) Dois-je utiliser `hard` ou `soft` pour éviter les « hangs » ?

Utilisez hard pour la correction, surtout pour les écritures. soft évite le blocage indéfini en renvoyant des erreurs,
mais change la sémantique et peut causer de la corruption de données avec des applications mal conçues.

2) Quelles sont de bonnes valeurs par défaut pour `timeo` et `retrans` ?

Commencez par les valeurs par défaut sauf preuve contraire. Une paire conservatrice courante est timeo=600,retrans=2 pour des LAN.
Sur un lien bruyant ou à latence élevée, augmentez timeo modestement ; ne faites pas que multiplier les retries.

3) Pourquoi je vois « server not responding » puis « OK » ?

Parce que le client retransmet les RPC et le serveur finit par répondre. Ce pattern indique souvent une perte réseau transitoire,
une surcharge serveur, ou des pics de latence du stockage derrière le serveur.

4) `x-systemd.automount` rend-il NFS plus fiable ?

Il rend le démarrage et le lancement de services plus résilients en évitant une dépendance forte sur la réussite immédiate du montage. Il ne répare pas un serveur lent,
mais empêche un serveur lent de casser des parties non liées du système.

5) Puis-je « réparer » les timeouts NFS en changeant `rsize`/`wsize` ?

Parfois vous pouvez réduire les symptômes, surtout sur des réseaux fragiles ou des appliances, mais ce n’est pas une correction de la cause.
Réglez pour la latence tail et la stabilité, pas pour le débit de pointe.

6) NFSv4 est-il toujours meilleur que NFSv3 ?

Pas toujours, mais généralement oui. NFSv4 est plus simple à firewaller et a une histoire protocolaire plus propre. NFSv3 peut convenir dans des environnements stables,
mais ajoute des services auxiliaires et des ports, ce qui augmente les modes de défaillance opérationnels.

7) Que signifie qu’un processus soit en état `D` ?

Il attend une E/S noyau qui ne peut pas être interrompue facilement. Si c’est lié à NFS, le noyau attend la complétion d’un RPC.
Résolvez la connectivité/la panne serveur sous-jacente ; n’attendez pas que kill -9 vous sauve.

8) Des problèmes de firewall/NAT peuvent-ils causer des timeouts NFS même si des connexions existent ?

Oui. Des firewalls stateful qui time-out des flux inactifs, du routage asymétrique, des trous MTU, et des ICMP filtrés peuvent tous provoquer des stalls
qui ressemblent à de la « flakiness NFS ». C’est pourquoi vous vérifiez les retransmissions TCP et les drops d’interface tôt.

9) Quand `nofail` est-il approprié ?

Pour des montages utiles mais non requis pour le boot ou la santé des services principaux — comme des outils partagés ou caches optionnels.
Ne l’utilisez pas pour des montages critiques sans mettre en place un gating de santé explicite pour vos services.

10) Si j’ai besoin de « ne jamais bloquer », que faire au lieu de NFS ?

Utilisez du stockage local avec réplication, ou une architecture qui tolère la défaillance du stockage distant : objet, artefacts adressés par contenu,
ou buffering écrit en arrière-plan avec garanties de durabilité claires. NFS est excellent, mais ce n’est pas une baguette magique.

Conclusion : quoi faire ensuite

Si vous retenez une leçon opérationnelle des timeouts NFS sur Debian 13, retenez celle-ci : les options de montage ne sont pas un remède,
ce sont un contrat. Définissez d’abord le contrat (hard vs soft, version du protocole, comportement au démarrage), puis mesurez où le système est réellement lent.

Étapes pratiques à faire cette semaine :

Inventoriez tous les montages NFS avec findmnt ; standardisez sur TCP et épinglez les versions lorsque c’est approprié.
Ajoutez x-systemd.automount et des timeouts de montage pour les montages non critiques afin d’éviter que le boot/services soient pris en otage.
Construisez un « pack d’incident NFS » minimal : nfsstat -c, nstat, ip -s link, logs noyau client, iostat serveur, et /proc/net/rpc/nfsd.
Réalisez un test de bascule/reboot contrôlé du serveur NFS et observez le comportement client, y compris les périodes de grâce, sous charge.
Quand vous devez tuner timeo/retrans, faites-le en expérimentation sur un canari, pas en dogme.