Les mises à jour NFS fusionnées pour la fenêtre Linux 7.3 apportent la pièce délibérément laissée de côté la fois précédente. NFSD prend désormais en charge CB_NOTIFY pour les délégations de répertoire NFSv4.1, ce qui permet au serveur de dire au client ce qui a changé dans un répertoire délégué au lieu de reprendre la délégation et d'imposer un rechargement complet. Les événements viennent de fsnotify, donc créations, suppressions, renommages et changements d'attributs du répertoire comptent tous. Les délégations en révocation seule avaient atterri les premières, en 2025, CB_NOTIFY étant explicitement reporté. Voici la suite, et c'est la moitié qui accélère les charges riches en LOOKUP.
The short answer
Les mises à jour NFS fusionnées pour la fenêtre Linux 7.3 donnent à NFSD la prise en charge de CB_NOTIFY pour les délégations de répertoire NFSv4.1. Au lieu de révoquer une délégation dès qu'un répertoire change, le serveur peut encoder une description du changement et l'envoyer au client, qui applique le delta et conserve le reste de son cache. Les événements viennent de fsnotify et couvrent créations, suppressions, renommages et changements d'attributs du répertoire. Les délégations en révocation seule avaient atterri en 2025, CB_NOTIFY étant volontairement reporté. Le même lot poursuit le travail Netlink de NFSD et retire les modes alternatifs de pool de threads du service.
L'essentiel de la latence NFS dont les gens se plaignent n'est pas du débit. C'est le coût de savoir si un fichier existe. Linux 7.3 s'attaque à ce point, et le fait en achevant un chantier sciemment laissé à moitié il y a un an.
Le problème de la révocation seule
Les délégations de répertoire sont l'équivalent, pour les répertoires, des délégations de fichiers que NFS possède depuis des années. Le client emploie l'opération NFSv4.1 GET_DIR_DELEGATION pour en demander une, et tant qu'il la détient, il sait que rien dans ce répertoire ne changera sans que le serveur le lui dise. Les LOOKUP et les readdir peuvent donc être servis localement, sans aller retour et sans les approximations des délais d'expiration du cache d'attributs.
L'implémentation de Jeff Layton pour knfsd a d'abord atterri en révocation seule. C'était un choix délibéré, énoncé clairement à l'époque : livrer la version la plus simple, en tirer de l'expérience, ajouter les notifications dans un noyau ultérieur.
La révocation seule fonctionne, mais elle manque de finesse. Tout changement du répertoire conduit le serveur à reprendre la délégation, et le client jette toute l'image mise en cache pour repartir de zéro. Sur un répertoire globalement stable, c'est très bien. Sur un répertoire qui reçoit un nouveau fichier toutes les quelques minutes, c'est un tapis roulant, et la délégation finit par coûter plus qu'elle ne rapporte.
Ce que change CB_NOTIFY
NFSD dans Linux 7.3 peut désormais envoyer un rappel CB_NOTIFY à la place. Plutôt que de révoquer sa promesse, le serveur décrit ce qui s'est passé.
Le mécanisme est direct. Les événements de changement arrivent via fsnotify, la machinerie de notification de modification de fichiers déjà présente dans le noyau, ce qui explique la couverture obtenue : créations, suppressions, renommages et changements des attributs propres du répertoire. Le serveur encode l'événement en XDR dans un tampon rattaché à la délégation, met le rappel en file, et le rappel récupère ce tampon pendant qu'un nouveau commence à collecter le lot suivant. Les événements s'accumulent et repartent groupés plutôt qu'un appel système à la fois.
Le résultat est la proportionnalité. Un fichier qui apparaît dans un répertoire de dix mille entrées coûte une petite notification, et non une révocation suivie d'une réénumération complète.
Pourquoi LOOKUP est la charge qui compte
Ouvrez un fichier situé à six répertoires de profondeur sur NFS et vous avez émis une chaîne d'appels LOOKUP, un par composant. Faites cela sur un arbre de compilation, une récupération de sources en intégration continue ou un répertoire de dépendances contenant des dizaines de milliers de petits fichiers, et le trafic LOOKUP domine tout le reste sur le montage.
Sans délégation, chacune de ces recherches dépend des délais d'expiration du cache d'attributs. Le client fait un pari sur l'obsolescence, et les conseils de réglage que l'on s'échange sont en réalité des conseils sur le degré d'erreur tolérable. Une délégation remplace le pari par une garantie, et CB_NOTIFY rend cette garantie viable sur des répertoires qui changent vraiment.
La meilleure indication de l'ampleur du gain vient d'ailleurs que de Linux. Rick Macklem a présenté une implémentation FreeBSD des délégations de répertoire lors d'un NFS Bakeathon précisément parce qu'elle améliore fortement les charges riches en LOOKUP. Le mécanisme est la même fonctionnalité de protocole, donc le raisonnement se transpose.
Le reste du lot
Deux autres éléments méritent attention pour qui administre des serveurs NFS.
NFSD poursuit la construction de sa prise en charge Netlink, entamée au cycle précédent. C'est le sens de la marche dans tout le noyau : configuration et introspection par Netlink plutôt que par une accumulation de fichiers procfs et de sysctl.
Plus visible immédiatement, les arrangements alternatifs de pool de threads du service NFSD ont été retirés, ne laissant que la gestion par nœud. Le motif est que le mode par nœud est la bonne réponse sur toute machine servant du NFS aujourd'hui. Si vous avez un script de réglage qui fixe un mode de pool de threads, le moment est venu de vérifier s'il faisait quoi que ce soit d'utile sur votre matériel, car après 7.3 il n'aura plus rien à fixer.
Quand vous pourrez l'utiliser
Pas tout de suite, et c'est normal. Il s'agit de travail côté serveur, et une délégation exige un client qui en demande une et comprenne le rappel. Les pièces côté client Linux suivent leur propre calendrier.
Linux 7.2 est sorti à la mi août 2026, ce qui place 7.3 en fin de fenêtre de fusion et une version stable à environ deux mois selon la cadence habituelle. Les noyaux de distributions arrivent plus tard encore, et NFS n'est pas un sous système où les gens sérieux se précipitent. La fenêtre réseau de 7.3 s'est refermée le 20 août, et le même cycle a apporté des gains Btrfs en entrées sorties directes allant jusqu'à 5x. Il y a un motif dans cette version : de la plomberie sans gloire, mesurée en allers retours économisés.
Sources et pour aller plus loin
- NFS Improvements Arrive For Linux 7.3, Phoronix, août 2026
- vfs, nfsd, nfs: implement directory delegations, LWN.net
- vfs: recall only directory delegations for knfsd, LWN.net, 17 octobre 2025
- NFSv4.1: Directory Delegations and Notifications, brouillon IETF
- CITI Experience with Directory Delegations, wiki Linux NFS
Questions fréquentes
Qu'est ce qu'une délégation de répertoire, en un paragraphe ?
C'est une promesse du serveur NFS au client à propos d'un répertoire précis. NFSv4.1 ajoute une opération GET_DIR_DELEGATION que le client emploie pour en demander une. Tant qu'il la détient, il sait que les entrées de ce répertoire ne changeront pas sans que le serveur le prévienne, ce qui lui permet de répondre aux LOOKUP et aux readdir depuis son propre cache au lieu de repasser sur le réseau à chaque fois. Les délégations de fichiers existent depuis bien plus longtemps et reposent sur le même principe. Les répertoires étaient le cas difficile, car un répertoire change dès que l'on crée, supprime ou renomme quoi que ce soit à l'intérieur.
Qu'apporte CB_NOTIFY que la révocation n'apportait pas ?
La proportionnalité. Avec des délégations en révocation seule, tout changement du répertoire conduit le serveur à reprendre la délégation, et le client jette tout ce qu'il avait mis en cache sur ce répertoire pour le recharger. C'est correct mais coûteux, et sur un répertoire qui change souvent cela peut être pire que de n'avoir jamais eu de délégation. CB_NOTIFY permet au serveur d'envoyer plutôt une description du changement. Le client applique le delta et conserve le reste de son cache. Un fichier qui apparaît dans un répertoire de dix mille entrées cesse de coûter une réénumération complète.
Quelles charges de travail en profitent réellement ?
Tout ce qui est riche en LOOKUP, c'est à dire en pratique tout ce qui parcourt des chemins. Les arbres de compilation partagés sur NFS, les répertoires personnels, les récupérations de sources en intégration continue, les répertoires de dépendances contenant des dizaines de milliers de petits fichiers et les boîtes aux lettres au format Maildir sont les cas classiques. Chaque stat sur un chemin profond est une chaîne d'appels LOOKUP, et sans délégation chaque maillon de cette chaîne est un aller retour gouverné par des délais d'expiration de cache plutôt que par une connaissance. L'implémentation FreeBSD des délégations de répertoire a été présentée lors d'un NFS Bakeathon précisément parce qu'elle améliore fortement les charges riches en LOOKUP.
Puis je m'en servir dès l'installation d'un noyau 7.3 ?
Pas à lui seul. Il s'agit de travail côté serveur dans NFSD, et une délégation est un arrangement à deux, donc le client doit en demander une et savoir quoi faire d'un rappel CB_NOTIFY. Les pièces côté client Linux arrivent séparément, à leur propre rythme. Linux 7.2 est sorti à la mi août 2026, donc 7.3 quitte tout juste sa fenêtre de fusion et une version stable est à environ deux mois selon la cadence habituelle, les noyaux de distributions venant plus tard encore. Prévoyez d'évaluer cela en 2027 plutôt que de l'activer ce trimestre.
Qu'y a t il d'autre dans le lot NFS de Linux 7.3 ?
Deux choses à connaître. NFSD poursuit la construction de la prise en charge Netlink entamée au cycle précédent, qui est la manière moderne de configurer et d'inspecter les sous systèmes du noyau plutôt que par les anciennes surfaces procfs et sysctl. Par ailleurs, les arrangements alternatifs de pool de threads du service NFSD ont été supprimés, ne laissant que la gestion par nœud, au motif que c'est le bon choix pour toute machine servant du NFS aujourd'hui. C'est une petite simplification au bénéfice réel : un bouton de réglage en moins, que beaucoup positionnaient sur la foi de conseils écrits pour du matériel très différent.