La mise à jour NFSD de Linux 7.3 ajoute CB_NOTIFY aux délégations de répertoire NFSv4.1. Le serveur peut signaler une modification pour qu’un client compatible entretienne son cache, au lieu de rappeler immédiatement la délégation.
Une autre réponse aux changements de répertoire
Les notes de NFSD indiquent que le serveur surveille les répertoires délégués avec fsnotify. Les notifications couvrent ajouts, suppressions, renommages et changements d’attributs du répertoire, avec des informations sur les entrées concernées.
Rappel et notification diffèrent. Le rappel demande au client de rendre sa délégation ; la notification transmet un changement. Décrire CB_NOTIFY comme un simple « rappel plus rapide » manque l’intérêt de ce travail.
Suivre un renommage
Imaginons un cache de répertoire contenant rapport.txt et notes.txt. Un autre client renomme rapport.txt en final.txt sur le serveur.
Avec une notification exploitable, le premier client peut mettre à jour l’entrée concernée tout en conservant ses connaissances utiles sur notes.txt. C’est le bénéfice conceptuel. L’exemple ne décrit pas l’encodage exact du renommage sur le réseau et ne promet pas l’absence de toute requête ultérieure.
Si le client ne peut pas utiliser la notification pertinente ou si sa délégation est rappelée, il doit suivre le chemin de cohérence prévu par le protocole. Garder indéfiniment une ancienne liste ne remplace pas le traitement de cet événement.
Le serveur a besoin d’un client compatible
La spécification NFSv4.1 définit délégations de répertoire et demandes de notification. Client installé, capacités négociées et charge réelle comptent. Mettre à jour le serveur ne démontre pas que tous les montages existants utiliseront ce mécanisme.
Une évaluation pratique noterait les versions des deux côtés, vérifierait l’attribution effective d’une délégation, puis observerait les callbacks pendant qu’un second client ajoute, supprime et renomme des entrées de test. Après chaque opération, comparez les noms visibles du premier client à l’état serveur. Mesurez les requêtes de répertoire séparément des transferts de fichiers volumineux.
Ce protocole de validation original ne constitue pas un résultat de test. Il vise l’effet attendu : conserver des informations de répertoire utiles malgré les changements. Il ne promet ni lectures disque plus rapides, ni gain de bande passante précis, ni baisse universelle du trafic NFS.
Dans les résultats, conservez les cas où aucune délégation n’a été accordée. Sinon, le benchmark peut comparer silencieusement un chemin avec notification à un chemin de cache ordinaire et attribuer toutes les différences au numéro du noyau.
Revue du 8 septembre : sources et suites de l’annonce vérifiées, explications et illustration reprises.