Debian 13 : SSHFS vs NFS — choisissez celui qui ne se fige pas aléatoirement (et configurez-le correctement) (cas n°21)

La décision : lequel ne se fige pas aléatoirement ?

Si votre exigence est « un montage qui ne se figera pas aléatoirement en production », la réponse honnête est :

• Choisissez NFSv4.1+ pour le stockage partagé en production (services, artefacts CI, répertoires personnels, volumes de conteneurs quand approprié), et configurez timeouts/retrans/semantiques d’automount pour que la panne ait une borne.
• Utilisez SSHFS pour les outils : accès ad hoc, migrations ponctuelles, debug, « j’ai besoin de ce répertoire maintenant », ou workflows développeur limités — mais traitez-le comme une couche de commodité, pas comme une plateforme de stockage.

Pourquoi ? Parce que les « figements aléatoires » ne sont généralement pas aléatoires. Ce sont des sémantiques bloquantes rencontrant un réseau instable, un serveur mort, ou une incohérence d’état. NFS dispose de décennies de réglages opérationnels pour définir ce que « down » signifie et comment les clients doivent se comporter. SSHFS est un système de fichiers FUSE reposant sur un protocole interactif (SFTP) qui n’a pas été conçu pour fournir des sémantiques POSIX strictes et à faible latence en cas de défaillance.

Cela dit : NFS peut aussi bloquer vos processus. Simplement, avec NFS vous pouvez choisir comment il échoue et rendre cela observable. Avec SSHFS, vous passez plus de temps à rétroconcevoir pourquoi une requête FUSE est coincée derrière un canal SSH bloqué.

Règle pratique : si un ls bloqué à 3 h du matin vous ferait pester, ne basez pas votre système sur SSHFS. Si un ls bloqué à 3 h du matin vous ferait pester, ne déployez pas non plus NFS sans options de montage explicites. Bienvenue dans le stockage.

Une citation pour rester lucide : L’espoir n’est pas une stratégie — Rick Page.

Blague #1 : SSHFS, c’est comme un canif. Génial jusqu’à ce que vous essayiez de refaire la maison avec.

Faits et historique pour étayer vos arguments

Points de contexte courts et concrets expliquant pourquoi ces outils se comportent ainsi :

1. NFS date de 1984 (Sun Microsystems). Il a été conçu pour des systèmes de fichiers Unix partagés sur LAN, avec une longue histoire d’ajustements opérationnels et des attentes d’entreprise.
2. NFSv4 est passé d’une « soupe RPC » à un protocole plus intégré, réduisant la dépendance à des démons/ports séparés comparé à NFSv3, et ajoutant des fonctionnalités d’état comme les délégations et de meilleurs verrous.
3. Les sémantiques de montage « hard » de NFS sont volontairement obstinées : le client réessaiera les E/S parce qu’échouer une écriture peut corrompre les hypothèses applicatives. Ce « blocage » est une fonctionnalité jusqu’à preuve du contraire.
4. SSHFS est un système de fichiers FUSE. Cela signifie que chaque opération traverse l’espace utilisateur, et le comportement de performance/latence dépend fortement du démon FUSE et de la gestion des requêtes.
5. SSHFS utilise SFTP, qui n’est pas « natif système de fichiers ». C’est un protocole de transfert de fichiers adapté pour apparaître comme un système de fichiers, ce qui crée des décalages autour des métadonnées et du verrouillage.
6. FUSE peut générer des processus apparemment impossible à tuer quand le noyau attend des réponses de l’espace utilisateur. Vous pouvez kill -9 le processus ; le noyau attendra toujours si la requête est bloquée.
7. NFS a un comportement bien connu de « stale file handle » quand des répertoires exportés changent sous le client (par ex., filesystem côté serveur remplacé, bascule mal gérée). C’est un classique, pas une nouveauté.
8. Les unités automount de systemd ont changé la donne pour les montages réseau : vous pouvez éviter les blocages au démarrage et borner les pannes en montant à l’accès plutôt qu’au boot.

Ce que « se figer » signifie réellement sous Linux

Quand on dit « le montage a gelé », Linux veut généralement dire l’un de ces cas :

1) Votre processus est en sommeil non interruptible (état D)

Classique pour les montages NFS hard, et aussi possible avec FUSE quand le noyau attend une réponse du démon FUSE. Si c’est vraiment en état D, le processus ne mourra pas tant que l’E/S sous-jacente ne se résout pas (souvent : elle ne se résout pas).

2) Votre shell est intact, mais tout chemin sous le montage bloque

C’est le mode de panne le plus furtif. La supervision vérifie la charge et l’espace disque et s’en remet. Pendant ce temps, tout ce qui touche /mnt/share est un arrêt complet.

3) « Blocage » est en réalité DNS ou auth

Les helpers de montage peuvent bloquer sur des requêtes DNS inverses, l’acquisition de tickets Kerberos, ou la communication avec rpcbind/mountd (NFSv3). Ça ressemble au stockage. C’est souvent la résolution de noms.

4) « Blocage » est le chemin réseau, pas le protocole

Mauvaise correspondance MTU, routage asymétrique, exhaustion de conntrack, firewall qui jette les fragments, un ToR instable, ou un VPN avec timeouts d’inactivité agressifs. SSH survit parfois mieux à certains de ces problèmes parce qu’il circule sur un flux TCP unique. Ou pire : il « survit » en se bloquant indéfiniment.

Opérationnellement, vous voulez deux choses :

• Panne bornée : les requêtes expirent et les appelants reçoivent des erreurs plutôt que des blocages infinis.
• Bonne observabilité : quand ça casse, vous pouvez voir pourquoi dans les logs/métriques et reproduire avec des outils simples.

SSHFS sur Debian 13 : ses points forts et où il vous piège

SSHFS est séduisant par sa simplicité. Vous avez déjà SSH. Lancez une commande, obtenez un montage. Pas de démon serveur à tuner (au-delà de sshd), pas d’exports, pas d’idmap, pas de réunion du comité firewall.

Et puis il commence à « se figer aléatoirement ». Voici pourquoi cela arrive et quoi faire.

Modèle de fiabilité SSHFS (ce que vous achetez réellement)

• Session TCP chiffrée unique (SSH) transportant des requêtes SFTP.
• Système de fichiers en espace utilisateur (FUSE) traduisant des opérations POSIX-ish en actions SFTP.
• La panne se présente souvent comme un « appel système bloqué » parce que le noyau attend FUSE, FUSE attend SSH, et SSH attend le réseau.

SSHFS est idéal quand le workflow tolère des pauses occasionnelles, ou quand « c’est en panne » signifie « je réessaierai » et rien ne sert de trafic utilisateur critique.

Déclencheurs courants de blocage SSHFS

• Sessions TCP inactives tuées par NAT/VPN : le canal SSH est toujours « up » du point de vue client mais le chemin est en blackhole.
• Surcharge côté serveur : sshd et le sous-système SFTP sont CPU-bound (chiffrement, compression, ou trop de sessions).
• Workloads riches en métadonnées : git status, recherches récursives, installations de dépendances. SSHFS tend à amplifier la latence et la sensibilité au RTT.
• Rétro-pression des requêtes FUSE : démon en espace utilisateur bloqué ; le noyau attend ; des processus s’accumulent.

Comment exécuter SSHFS sans s’auto-saboter

Sur Debian 13, supposez que vous utilisez sshfs avec FUSE3. Les tactiques :

• Utilisez des keepalives SSH pour détecter les chemins morts.
• Utilisez l’automount pour qu’un serveur mort n’empêche pas le démarrage ou les services qui n’en ont pas besoin.
• Acceptez que le caching soit délicat. Trop de cache améliore la vitesse et augmente le risque de vue obsolète ; trop peu de cache peut transformer un repo en banc de test de latence.
• Ne prétendez pas que le verrouillage est parfait. Si vous avez besoin d’un comportement POSIX multi-client correct, SSHFS est le mauvais outil.

Blague #2 : Le moyen le plus rapide de trouver un problème SSHFS est d’annoncer que vous « allez juste l’utiliser en production — temporairement ».

NFS sur Debian 13 : production-grade, si vous le respectez

NFS a mauvaise réputation pour deux raisons : des gens qui ont utilisé NFSv3 sur des réseaux instables, et des gens qui ont laissé les valeurs par défaut intactes puis été surpris quand le comportement par défaut est survenu.

Modèle de fiabilité NFS

Les clients NFS rendent l’E/S distante locale. Quand le serveur ou le chemin échoue, le client décide quoi faire selon les options de montage :

• Montages hard : réessaient en boucle. Excellent pour l’intégrité des données, dangereux pour la disponibilité si vous ne maîtrisez pas le rayon d’impact.
• Montages soft : abandonnent et renvoient une erreur. Mieux pour les outils interactifs et les lectures « best effort » ; risqué pour les écritures.
• Timeouts et retrans : définissent combien de temps vous attendez et à quel rythme vous réessayez.
• Systemd automount : ne monte qu’à l’accès, et évite les blocages au démarrage.

À quoi ressemble un « blocage aléatoire » en terre NFS

Il s’agit presque toujours d’un de ces cas :

• Montage hard + serveur inaccessible ⇒ tâches en état D, potentiellement en accumulation.
• Problèmes de verrouillage / récupération d’état après reboot serveur ⇒ blocages ou erreurs d’E/S selon la version et la charge.
• Incohérence DNS/idmap ⇒ bizarreries de permissions qui ressemblent à des bugs applicatifs.
• Médication firewall/NAT ⇒ stalls intermittents sous charge (surtout avec les services additionnels de NFSv3).

Que déployer par défaut

Si vous voulez une baseline sensée pour des clients Debian 13 :

• NFSv4.1 ou plus récent (4.2 si votre serveur le supporte), TCP.
• Systemd automount pour tout ce qui n’est pas essentiel au démarrage ; pour les montages essentiels, soyez explicite sur les dépendances et les timeouts.
• Montages hard pour les données critiques en écriture, mais isolez-les (service séparé, namespace de montage séparé si nécessaire) et surveillez les E/S bloquées.
• Montages soft uniquement pour les accès majoritairement lecture non critiques, et seulement si votre application tolère des erreurs d’E/S.

Une panne bornée avec NFS ne signifie pas « jamais hard ». Cela signifie : hard là où la cohérence compte, et entouré de garde-fous pour qu’il ne fige pas tout l’hôte.

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

Voici les vérifications que j’exécute réellement quand une alerte de « blocage aléatoire » arrive. Chaque tâche inclut ce que la sortie implique et quelle décision prendre ensuite.

Task 1 — Identifier ce qui est monté et comment

cr0x@server:~$ findmnt -t nfs,nfs4,fuse.sshfs
TARGET      SOURCE                  FSTYPE     OPTIONS
/mnt/build  nfs01:/exports/build    nfs4       rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,proto=tcp,sec=sys,clientaddr=10.0.2.10
/mnt/tools  dev@jump:/srv/tools     fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000

Sens : vous voyez le protocole, la version, et si NFS est hard/soft. SSHFS apparaît comme fuse.sshfs.

Décision : si NFS est en hard et que le montage est sous un chemin utilisé par des services critiques (comme des sous-arbres de /var), priorisez la réduction du rayon d’impact (automount ou isolation de service).

Task 2 — Vérifier la négociation de version NFS depuis le client

cr0x@server:~$ nfsstat -m
/mnt/build from nfs01:/exports/build
 Flags:	rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.10

Sens : cela confirme ce que le noyau utilise réellement, pas seulement ce que vous pensez avoir configuré.

Décision : si ça indique vers=3 alors que vous attendiez v4, investiguez le support serveur, les options de montage, et les règles firewall (v3 est plus fragile sur les réseaux).

Task 3 — Détecter les processus « bloqués » et s’ils sont en état D

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2 ~ /D/ {print}'
23144 D  rsync  nfs_wait_on_request        rsync -a /mnt/build/ /var/cache/build/

Sens : un état D avec des wait channels nfs_* crie « bloqué sur I/O NFS ». Si c’est fuse_wait, pensez SSHFS/FUSE.

Décision : arrêtez de redémarrer bêtement les applications. Vous savez maintenant que c’est une attente d’E/S noyau ; concentrez-vous sur le réseau/le serveur, pas sur l’application.

Task 4 — Vérifier les logs noyau pour les erreurs client NFS

cr0x@server:~$ journalctl -k -n 50 --no-pager
Dec 30 10:12:03 server kernel: NFS: server nfs01 not responding, still trying
Dec 30 10:12:33 server kernel: NFS: server nfs01 not responding, still trying
Dec 30 10:13:04 server kernel: NFS: server nfs01 OK

Sens : problèmes transitoires serveur/chemin. Si vous voyez « still trying » de manière répétée, le client est coincé dans des boucles de retry (comportement hard).

Décision : si cela se produit fréquemment, ajustez les timeouts et investiguez les coupures réseau ; ne « réparez » pas ça en ajoutant plus de retries applicatifs.

Task 5 — Confirmer l’export serveur depuis le client

cr0x@server:~$ showmount -e nfs01
Export list for nfs01:
/exports/build 10.0.2.0/24

Sens : valide que le serveur exporte et que votre réseau est autorisé. (Surtout pertinent pour NFSv3 ; utile aussi pour des vérifications de sanity.)

Décision : si cela échoue ou bloque, suspectez firewall/services rpc, ou une mauvaise résolution DNS.

Task 6 — Valider la résolution de noms et le reverse DNS (oui, ça compte)

cr0x@server:~$ getent hosts nfs01
10.0.2.20       nfs01
cr0x@server:~$ getent hosts 10.0.2.20
10.0.2.20       nfs01

Sens : résolution avant/arrière cohérente. Une résolution incohérente provoque des délais, des problèmes d’auth et des comportements intermittents.

Décision : si la recherche inverse est lente ou erronée, corrigez le DNS ou ajoutez des entrées sensées dans la pile de résolveur appropriée. N’acceptez pas des stalls DNS de 5 secondes sur chaque chemin de montage.

Task 7 — Mesurer RTT et perte de paquets de base vers le serveur

cr0x@server:~$ ping -c 5 nfs01
PING nfs01 (10.0.2.20) 56(84) bytes of data.
64 bytes from 10.0.2.20: icmp_seq=1 ttl=64 time=0.41 ms
64 bytes from 10.0.2.20: icmp_seq=2 ttl=64 time=0.38 ms
64 bytes from 10.0.2.20: icmp_seq=3 ttl=64 time=0.43 ms
64 bytes from 10.0.2.20: icmp_seq=4 ttl=64 time=0.40 ms
64 bytes from 10.0.2.20: icmp_seq=5 ttl=64 time=0.39 ms

--- nfs01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4090ms
rtt min/avg/max/mdev = 0.38/0.40/0.43/0.02 ms

Sens : la connectivité de base a l’air correcte, mais ping n’est pas une preuve que NFS/SSH ne va pas staller. Néanmoins, une perte ici est un signal d’alerte.

Décision : s’il y a perte de paquets, corrigez le réseau d’abord. Le tuning stockage est vain sur un chemin qui perd des paquets.

Task 8 — Vérifier MTU ou bizarreries de chemin avec tracepath

cr0x@server:~$ tracepath nfs01
 1?: [LOCALHOST]                                         pmtu 1500
 1:  nfs01                                                0.439ms reached
     Resume: pmtu 1500 hops 1 back 1

Sens : PMTU est sain et le chemin est simple. Si PMTU baisse de façon inattendue, vous pouvez voir le risque de fragmentation.

Décision : si PMTU est plus faible que prévu (ex. 1400 sur un LAN), vérifiez overlays/VPNs et alignez le MTU pour éviter des stalls intermittents.

Task 9 — Vérifier les settings keepalive SSH pour les scénarios SSHFS

cr0x@server:~$ ssh -G jump | egrep 'serveraliveinterval|serveralivecountmax|tcpkeepalive'
tcpkeepalive yes
serveraliveinterval 15
serveralivecountmax 3

Sens : SSH détectera les chemins morts en ~45 secondes. Sans cela, SSH peut rester sur une session TCP morte longtemps selon le réseau.

Décision : si ces paramètres sont absents ou trop élevés, ajoutez-les à votre invocation SSHFS ou à la config SSH pour faire échouer les pannes.

Task 10 — Reproduire le « blocage » avec un seul appel système et un wrapper timeout

cr0x@server:~$ timeout 5s stat /mnt/build/. || echo "stat timed out"
stat timed out

Sens : cela prouve que le blocage est dans l’accès au système de fichiers, pas dans le programme appelant. Utiliser timeout le rend visible et scriptable.

Décision : si stat bloque mais ping est ok, suspectez starvation de threads NFS côté serveur, problèmes d’état firewall, ou RPC client bloqués.

Task 11 — Inspecter l’activité RPC NFS en direct (côté client)

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

Client nfs v4:
null         read         write        commit       open         open_conf
3            20811        14402        0            9812         14

Sens : une augmentation rapide des retrans suggère perte de paquets ou lenteur serveur. Un petit compteur retrans stable en temps normal est acceptable ; les pics ne le sont pas.

Décision : si retrans augmente lors d’incidents, traitez-le comme un problème réseau/capacité serveur, pas « NFS c’est nul ».

Task 12 — Confirmer l’ordonnancement systemd et le risque au boot

cr0x@server:~$ systemctl show -p After -p Wants remote-fs.target
After=network-online.target
Wants=network-online.target

Sens : vos montages distants sont liés à network-online.target. Si network-online est instable, le boot peut être lent ou bloqué.

Décision : pour des montages non-critiques, basculez vers systemd automount pour que le système démarre même si le stockage est indisponible.

Task 13 — Repérer rétro-pression SSHFS/FUSE et requêtes bloquées

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | egrep 'sshfs|fuse' | head
18211 S  sshfs  wait_woken                     sshfs dev@jump:/srv/tools /mnt/tools -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3

Sens : pas encore en état D, mais vous pouvez corréler le timing avec un rapport de stall. Si vous voyez beaucoup de processus coincés en fuse_wait ou similaire, SSHFS est bloqué.

Décision : si ça se bloque régulièrement sous charge, cessez d’utiliser SSHFS pour cette charge. C’est un mauvais choix de conception, pas un problème de tuning.

Task 14 — Confirmer que le serveur NFS est joignable sur le bon port (v4)

cr0x@server:~$ nc -vz nfs01 2049
Connection to nfs01 (10.0.2.20) 2049 port [tcp/nfs] succeeded!

Sens : TCP/2049 est ouvert. NFSv4 a principalement besoin de ça. Si ça échoue de manière intermittente, suspectez firewall state ou load balancers « aidants ».

Décision : si 2049 est bloqué, arrêtez tout. Aucune option de montage ne contournera « port fermé ». Corrigez la politique réseau.

Task 15 — Vérifier les options de montage effectives depuis /proc (vérité terrain)

cr0x@server:~$ grep -E ' /mnt/build | /mnt/tools ' /proc/mounts
nfs01:/exports/build /mnt/build nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.10 0 0
dev@jump:/srv/tools /mnt/tools fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

Sens : c’est ce que le noyau utilise. Si vous pensez avoir appliqué une option et qu’elle n’est pas ici, elle ne s’est pas appliquée.

Décision : corrigez l’unité de montage/fstab/la commande et remontez.

Playbook de diagnostic rapide

Quand quelqu’un dit « le montage distant a gelé », vous pouvez perdre une heure à deviner. Ou vous pouvez faire ceci en cinq minutes et avoir l’air préparé.

Première étape : déterminer si c’est NFS ou SSHFS, et s’il y a des processus en état D

• Exécutez : findmnt -t nfs,nfs4,fuse.sshfs et ps ... | awk '$2 ~ /D/'
• Si l’état D existe : c’est une attente d’E/S noyau. Redémarrer les applis ne corrigera pas. Passez aux vérifications réseau/serveur.
• Si pas d’état D : ça peut quand même être lent/bloqué en espace utilisateur (SSHFS) ou lié à la résolution/auth.

Deuxième étape : vérifier la preuve de vie la plus simple pour le chemin de montage précis

• Exécutez : timeout 5s stat /mnt/whatever
• Si stat bloque : vous avez reproduit avec un appel système. Maintenant corrélez avec les logs, les stats RPC et le réseau.
• Si stat fonctionne : votre « blocage » est probablement dans des couches supérieures (lock applicatif, traversée de répertoire énorme, métadonnées lentes).

Troisième étape : isoler le domaine — réseau, serveur, client ou sémantique

• Réseau : ping, tracepath, vérifier retrans dans nfsstat -rc, tester le port 2049 avec nc.
• Serveur : recherchez « server not responding » dans les logs noyau ; si vous y avez accès, vérifiez la saturation des threads NFS et la latence disque (hors scope ici, mais vous connaissez la procédure).
• Configuration client : confirmez les options de montage dans /proc/mounts et ce que systemd fait au boot.
• Inadéquation sémantique : si le workload est riche en métadonnées et que vous êtes sur SSHFS, arrêtez. Si vous exigez des sémantiques d’échec strictes mais que vous montez NFS en hard sur un chemin critique, repensez l’architecture.

Erreurs courantes (symptômes → cause → correction)

1) Symptom : « L’hôte entier est figé », mais seules certaines commandes bloquent

Cause racine : un shell ou un service système a touché un chemin NFS hard-monté ; des processus sont coincés en état D en attente d’E/S.

Correction : utilisez x-systemd.automount pour les montages non critiques, et évitez de placer NFS sous des chemins utilisés par des services cœur. Pour les montages critiques, isolez les services et surveillez les stalls NFS.

2) Symptom : montage SSHFS fonctionne, puis « gèle » après une inactivité

Cause racine : timeout d’inactivité NAT/VPN qui met le flux TCP en blackhole ; SSH ne le détecte pas rapidement sans keepalives.

Correction : configurez ServerAliveInterval et ServerAliveCountMax (côté client), et songez au TCP keepalive. Préférez l’automount pour qu’il soit ré-établi à l’accès.

3) Symptom : les montages NFS prennent parfois 30–90 secondes, parfois instantané

Cause racine : délais de lookup DNS inverses ou résolveur intermittent ; ou tentative de négociation de versions/ports qui expire avant fallback.

Correction : corrigez la cohérence DNS ; spécifiez vers=4.2 explicitement ; assurez-vous que TCP/2049 est permis de bout en bout.

4) Symptom : « Permission denied » sur NFSv4 malgré UID/GID identiques

Cause racine : désalignement idmapping/domaine ou export fait avec root_squash qui ne correspond pas au modèle d’identité client.

Correction : alignez les paramètres idmap si vous dépendez du mapping par nom, ou utilisez des IDs numériques cohérents entre systèmes. Vérifiez les options d’export côté serveur.

5) Symptom : « Stale file handle » après maintenance/basculement

Cause racine : filesystem côté serveur remplacé/déplacé ; les clients conservent des références aux anciens filehandles.

Correction : remontez le filesystem ; évitez de remplacer des arbres exportés sans remount coordonné des clients ou sans sémantiques HA appropriées.

6) Symptom : les jobs CI rament sur SSHFS ; CPU explose des deux côtés

Cause racine : opérations riches en métadonnées via SFTP chiffré + contexte FUSE ; la compression optionnelle aggrave le problème.

Correction : utilisez NFS pour les artefacts de build ; si vous devez utiliser SSHFS, désactivez la compression sur le LAN et évitez les chemins chauds.

7) Symptom : le démarrage bloque en attente de montages distants

Cause racine : montages dans /etc/fstab sans automount ; network-online target pas réellement up ; montage hard en attente.

Correction : utilisez nofail, x-systemd.automount, et x-systemd.mount-timeout= ; assurez-vous que network-online est correctement implémenté pour votre pile réseau.

8) Symptom : NFS fonctionne, mais certaines applis ont des comportements étranges (verrous, écritures partielles, erreurs bizarres)

Cause racine : usage de soft pour des workloads qui supposent que les écritures ne peuvent pas échouer en cours de route ; ou mélange de versions NFS anciennes avec des attentes de lock.

Correction : utilisez hard pour les workloads critiques en écriture ; assurez-vous d’être sur NFSv4 et d’avoir le bon maniement des locks/états ; repensez les applis pour gérer des erreurs d’E/S si vous insistez sur soft.

Checklists / plan pas à pas

Plan A : Vous avez besoin d’un système de fichiers partagé fiable (la plupart des cas production)

1. Choisissez NFSv4.2 sur TCP sauf raison impérieuse contraire.
2. Décidez la sémantique de panne par montage :
   • Écriture critique : hard, mais isolez.
   • Lecture majoritaire et non critique : envisagez soft avec timeouts courts.
3. Utilisez systemd automount pour tout ce qui n’est pas requis au boot.
4. Définissez des timeouts et retrans explicites au lieu de faire confiance à des valeurs par défaut non testées.
5. Surveillez les messages « server not responding » et les pics de retrans.
6. Documentez le rayon d’impact : quels services touchent le montage ? quelles machines ? que se passe-t-il si ça bloque ?

Plan B : Vous avez juste besoin d’un accès ad-hoc sécurisé (outils développeur, migrations)

1. Utilisez SSHFS avec keepalives et reconnect.
2. Évitez les workflows riches en métadonnées (gros dépôts, gestionnaires de paquets) sur SSHFS quand la vitesse ou la stabilité compte.
3. Montez à la demande avec systemd ou commandes manuelles, pas comme dépendance critique de boot.
4. Privilégiez rsync/scp pour les transferts bulk quand vous n’avez pas besoin d’une vue montée.

Extraits de configuration Debian 13 que vous pouvez réellement déployer

Paquets client NFS et entrée fstab sensée (avec automount)

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y nfs-common
...output...

cr0x@server:~$ sudo mkdir -p /mnt/build
cr0x@server:~$ sudo sh -c 'printf "%s\n" "nfs01:/exports/build /mnt/build nfs4 rw,vers=4.2,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,x-systemd.automount,x-systemd.idle-timeout=300,noatime,nofail,x-systemd.mount-timeout=30s 0 0" >> /etc/fstab'

Ce que ça vous apporte : l’hôte démarre même si NFS est down (nofail), le montage a lieu à l’accès (automount), et s’il ne peut pas monter rapidement, il échoue vite plutôt que de bloquer indéfiniment au boot.

SSHFS avec keepalives et reconnect (montage manuel)

cr0x@server:~$ sudo apt-get install -y sshfs
...output...
cr0x@server:~$ sudo mkdir -p /mnt/tools
cr0x@server:~$ sshfs dev@jump:/srv/tools /mnt/tools -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,IdentityFile=/home/dev/.ssh/id_ed25519,allow_other

Note opérationnelle : allow_other nécessite user_allow_other dans /etc/fuse.conf. Utilisez-le seulement si c’est volontaire ; sinon gardez les montages privés à l’utilisateur.

Systemd automount pour SSHFS (pour qu’il ne coince pas le boot)

Quand SSHFS est utilisé par un service, je préfère des unités systemd pour définir timeouts et comportement de restart.

cr0x@server:~$ sudo tee /etc/systemd/system/mnt-tools.mount &>/dev/null <<'EOF'
[Unit]
Description=SSHFS tools mount
After=network-online.target
Wants=network-online.target

[Mount]
What=dev@jump:/srv/tools
Where=/mnt/tools
Type=fuse.sshfs
Options=_netdev,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,IdentityFile=/home/dev/.ssh/id_ed25519,allow_other

[Install]
WantedBy=multi-user.target
EOF
...output...

cr0x@server:~$ sudo tee /etc/systemd/system/mnt-tools.automount &>/dev/null <<'EOF'
[Unit]
Description=Automount SSHFS tools

[Automount]
Where=/mnt/tools
TimeoutIdleSec=300

[Install]
WantedBy=multi-user.target
EOF
...output...

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now mnt-tools.automount
Created symlink /etc/systemd/system/multi-user.target.wants/mnt-tools.automount → /etc/systemd/system/mnt-tools.automount.

Décision : si le serveur SSHFS est down, les accès à /mnt/tools tenteront le montage et échoueront dans les contraintes de timeout de systemd, plutôt que de bloquer le boot.

Trois mini-histoires d’entreprise du terrain

Histoire 1 : l’incident causé par une mauvaise hypothèse (« c’est juste un montage »)

Une entreprise de taille moyenne utilisait Debian sur des runners de build. Quelqu’un avait besoin d’un accès rapide à un store d’artefacts legacy accessible uniquement via SSH à travers un jump host fortifié. SSHFS était l’évidence : pas de demande firewall, pas de changement serveur, et ça fonctionnait pendant les cinq premières minutes.

Ils ont intégré le montage SSHFS dans /etc/fstab sur les runners parce que le job CI attendait /mnt/artifacts. C’était « temporaire », ce qui en langage entreprise veut dire « jusqu’à la prochaine réorg ». Pendant des semaines ça a semblé correct, parce que le chemin réseau était stable et le jump host peu utilisé.

Puis un changement VPN a introduit un timeout d’inactivité. Les sessions SSH silencieuses n’étaient pas correctement fermées ; elles étaient en blackhole. Les appels SSHFS commencèrent à bloquer. Les workers CI n’étaient pas down ; pire : ils étaient up et brûlaient des slots d’exécuteurs sur des jobs qui bloquaient pendant tar extraction.

La mauvaise hypothèse était qu’un montage est comme un répertoire local avec un profil de latence différent. Ce n’est pas ça. C’est une dépendance avec des modes de panne. Quand elle casse, ça casse souvent à l’intérieur d’appels systèmes où votre appli ne peut pas « attraper » l’erreur.

La correction n’a rien d’héroïque : retirer SSHFS de fstab, ajouter systemd automount avec keepalives, et migrer le store d’artefacts vers NFS derrière le firewall où il avait sa place. Le changement le plus important fut culturel : les montages distants furent traités comme des bases de données — possédés, monitorés et revus.

Histoire 2 : l’optimisation qui s’est retournée contre eux (plus gros n’est pas toujours mieux)

Une autre équipe avait un partage NFS utilisé par des jobs analytiques. Ils ont constaté des problèmes de débit et ont fait ce que tout le monde fait : augmenter rsize et wsize, activer un caching client agressif, et célébrer quand un benchmark séquentiel rendait mieux.

Ce n’était pas malveillant. C’était normal. Une personne a lancé un test de lecture séquentielle et obtenu un joli chiffre. Puis la charge a changé : des milliers de petits fichiers, beaucoup d’opérations métadonnées, et plusieurs clients. Soudain la configuration « rapide » a produit de longs stalls aux heures de pointe.

Le revers est venu de deux côtés. D’abord, de plus grosses tailles d’I/O n’aident pas les workloads riches en métadonnées et parfois ralentissent la récupération quand des paquets sont perdus (plus de données à retransmettre). Ensuite, la sémantique automount/timeout de l’équipe était encore par défaut, donc quand le serveur s’occupait, les clients s’empilaient en retries et tout semblait gelé.

Ils ont corrigé en traitant le tuning comme spécifique au workload. Ils ont gardé les grandes tailles pour le chemin de données séquentiel mais séparé les arbres métadonnées vers des exports différents et imposé des timeouts clients sensés. La plus grosse amélioration vint de rendre les pannes visibles et bornées, pas d’arracher 5 % de throughput en plus.

Histoire 3 : la pratique ennuyeuse et correcte qui a sauvé la mise (et personne n’a eu de trophée)

Un environnement régulé montait des répertoires personnels via NFS. Tout le monde craignait les « NFS hangs », donc la tentation était d’utiliser des montages soft partout. Mais l’équipe ops a fait quelque chose d’extrêmement terne : classifier les montages selon l’exigence de correction et appliquer des politiques en conséquence.

Les répertoires personnels étaient montés hard car perdre des écritures était inacceptable. Mais ils étaient aussi montés avec systemd automount et tenus à l’écart des chemins critiques au boot. Les sessions utilisateur bloquaient si le filer mourait, mais l’hôte restait gérable. Cette distinction compte quand il s’agit de réparer.

Ils avaient aussi une vérification hebdomadaire : échantillonner la latence de stat, surveiller le taux de messages noyau « not responding », et alerter sur des pics de retrans NFS. Rien d’extravagant. Pas de buzzwords. Juste de petites vérifications qui détectent « ça devient bizarre » avant que ça n’explose.

Quand une maintenance réseau causa une brève perte de paquets, ils virent retrans monter et les messages « server not responding ». Comme ils avaient des baselines, ils purent dire « C’est anormal et ça corrèle avec la fenêtre de changement ». La correction fut rapide et l’impact utilisateur limité.

Le meilleur : le runbook a marché même pour des nouvelles personnes en on-call. Le système ne dépendait pas d’un magicien connaissant la panne de 2019.

FAQ

1) Lequel est plus rapide sur Debian 13 : SSHFS ou NFS ?

Pour la plupart des workloads réels, NFS est plus rapide et plus prévisible, surtout en concurrence et pour les accès riches en métadonnées. SSHFS ajoute un surcoût de chiffrement, des traversées espace utilisateur, et la traduction SFTP.

2) Lequel est plus sûr par défaut ?

SSHFS hérite du chiffrement et de l’authentification SSH, donc il est souvent plus simple à déployer en sécurité sur des réseaux non fiables. NFS peut être sécurisé, mais il faut le concevoir : isolation réseau, firewalling, et (si besoin) Kerberos.

3) Qu’est-ce qui cause réellement les « blocages aléatoires » sur NFS ?

Le plus souvent : les montages hard qui réessaient lors de problèmes serveur/chemin, perte de paquets réseau provoquant des tempêtes de retrans, ou douleur de récupération d’état/verrouillage pendant les redémarrages serveur. La correction est généralement des sémantiques d’échec meilleures plus la résolution du problème réseau/serveur.

4) Peut-on rendre SSHFS « non bloquant » ?

Vous pouvez réduire la probabilité en utilisant keepalives et automount, mais vous ne pouvez pas changer le fait que FUSE + SFTP peut bloquer des appels système quand le canal est en rade. Si « ne jamais se figer » est votre exigence, ne mettez pas SSHFS sur des chemins critiques.

5) Dois-je utiliser des montages soft NFS pour éviter les blocages ?

Uniquement pour des workloads majoritairement lecture et non critiques où votre application peut tolérer des erreurs d’E/S. Les montages soft échangent « bloquer pour toujours » contre « échouer parfois », et échouer des écritures en cours de route peut causer des corruptions subtiles côté application.

6) Systemd automount est-il meilleur qu’autofs ?

Pour beaucoup d’installations Debian 13, systemd automount est plus simple et s’intègre bien à l’ordonnancement du boot et aux timeouts. Autofs reste valable quand vous avez besoin d’une logique de maps avancée ou d’un comportement legacy.

7) Quelles options de montage comptent le plus pour éviter la douleur à l’échelle de l’hôte ?

x-systemd.automount (éviter la dépendance au boot et borner l’accès), nofail, et des timeo/retrans explicites pour que vous sachiez ce que « down » signifie. Aussi : ne montez pas de systèmes distants sous des chemins dont dépendent les services cœur à moins d’en avoir l’intention.

8) Pourquoi df bloque quand le montage est cassé ?

df interroge les stats de tous les montages. Si un montage distant bloque, df bloque. Utilisez df -l pour local-only, ou ciblez des filesystems spécifiques.

9) NFS est-il acceptable sur Wi‑Fi ou l’internet public ?

Sur Wi‑Fi : ça peut fonctionner, mais attendez-vous à de la variabilité et des retrans. Sur l’internet public : évitez, sauf si vous maîtrisez le transport sécurisé, les attentes de latence, et les sémantiques de panne. Les outils basés SSH sont généralement un meilleur choix pour cet environnement.

10) Quelle est la recommandation par défaut la plus simple et sûre ?

NFSv4.2 avec systemd automount pour les partages production ; SSHFS avec keepalives pour l’accès ad-hoc uniquement. Si vous êtes tenté d’inverser ces choix, vous êtes sur le point d’apprendre quelque chose de coûteux.

Conclusion : que faire lundi matin

Si vous ne retenez qu’une chose : les systèmes de fichiers distants sont des dépendances qui échouent à l’intérieur d’appels systèmes. Choisissez le protocole qui correspond à votre tolérance aux pannes, puis configurez-le pour que la panne soit bornée et observable.

1. Inventoriez les montages avec findmnt et classez-les : écritures critiques vs lectures de commodité.
2. Migrer les chemins partagés de production vers NFSv4.2 quand c’est possible. Gardez SSHFS pour les outils, pas pour les fondations.
3. Ajoutez systemd automount pour les montages non critiques au boot. Faites de « stockage down » un état récupérable.
4. Définissez timeouts et keepalives explicites (NFS timeo/retrans ; SSH ServerAliveInterval/CountMax).
5. Rédigez une page de runbook avec les étapes de diagnostic rapide : contrôle d’état D, timeout stat, logs, retrans, port reachability.

L’objectif n’est pas « ne jamais tomber en panne ». L’objectif est « tomber d’une façon que vous pouvez survivre, diagnostiquer et expliquer sans mentir ». C’est ce qui empêche les montages de devenir des mystères — et ce qui évite que votre on-call n’apprenne de nouveaux jurons.