Résumé

  • La révision 11 interdit à un client qui honore l’attribut de servir un nouveau parcours avec le résultat READDIR d’un parcours antérieur, puis de présenter pour une entrée une valeur reçue avant le READDIR qui vient de la renvoyer.
  • La règle porte sur ce que voit l’application, non sur l’organisation interne du cache. Elle est limitée au répertoire, à l’entrée effectivement renvoyée et à l’état que le serveur pouvait indiquer à cet instant.
  • Cette précision réduit un risque réel pour les sauvegardes et synchronisations, au prix d’un trafic récurrent qu’il faut mesurer, autoriser avec parcimonie et tester client par client.

Une sauvegarde peut croire un nom et se tromper de taille

Le défaut n’est pas une incohérence du répertoire lui-même. Le couple nom–fileid peut rester valable : personne n’a créé, supprimé ni renommé l’entrée. Pourtant, un autre client peut continuer d’écrire dans le fichier. La taille et time_modify changent alors sans déplacer l’attribut change du répertoire parent.

Un client NFS peut conserver les attributs reçus à côté des entrées lors d’un READDIR. C’est efficace : le prochain stat n’exige pas un GETATTR par fichier. Dans une zone d’ingestion ou de calcul où des centaines de producteurs écrivent, cette économie transforme toutefois une photographie correcte des noms en récit périmé des fichiers. Une sauvegarde incrémentale peut conclure qu’un fichier n’a pas bougé et ne pas copier les nouveaux octets.

L’attribut fattr4_uncacheable_dirent_metadata permet au serveur de signaler les répertoires où ce compromis devient dangereux. L’absence du signal ne certifie pas les autres caches. Sa présence crée seulement une obligation supplémentaire pour le client qui décide de l’honorer.

La révision 11 abandonne une formule invérifiable

Le projet draft-ietf-nfsv4-uncacheable-directories-11 a été déposé le 5 septembre 2026. C’est un document actif du groupe NFSv4, destiné au parcours des normes. Les prototypes Hammerspace et Linux sont rapportés par les contributeurs. Rien de cela n’en fait une RFC, une approbation de l’IETF ni une preuve de déploiement.

Dans la révision 10, le client devait récupérer les métadonnées du serveur « à chaque READDIR ». Or READDIR est déjà l’opération réseau adressée au serveur. Cette phrase n’empêchait pas clairement le client de rafraîchir les noms puis d’exposer une taille plus ancienne issue de son cache ordinaire d’attributs.

La nouvelle rédaction vise le résultat observable. Pour un répertoire marqué, le client ne peut pas satisfaire une nouvelle énumération avec des résultats READDIR provenant d’une autre énumération. Quand un READDIR renvoie une entrée, la valeur présentée pour cette entrée ne peut pas avoir été reçue avant ce READDIR, quelle que soit l’opération qui l’avait auparavant placée dans le cache.

On peut donc construire un test de conformité sans connaître la mémoire du noyau : premier parcours, écriture concurrente, second parcours, puis observation du fichier. C’est l’ancienne valeur, antérieure au READDIR du second parcours, qui est interdite. Le client reste libre de la conserver tant qu’il ne s’en sert pas pour produire cette réponse.

Une énumération n’est pas un appel par entrée

La révision définit trois niveaux que le mot « readdir » mélangeait. Le readdir en minuscules est la demande de l’application. READDIR en capitales est l’opération NFSv4.2. Une énumération est un passage complet ou partiel sur le répertoire ; plusieurs appels applicatifs sont normalement alimentés par un même READDIR, et un grand répertoire exige des READDIR de continuation.

La règle n’impose donc pas une requête réseau pour chaque nom. Elle exige que le nouveau passage repose sur les READDIR de ce passage. Le client devrait demander dans attr_request les attributs qu’il compte montrer. Il peut lancer des GETATTR ensuite, mais un GETATTR par entrée recrée précisément la charge que le READDIR enrichi évite.

Les valeurs du passage peuvent rester en cache. Entre deux énumérations, la durée de vie normale des attributs définie par la RFC 8881 continue de s’appliquer. Le prochain passage est la frontière qui rend inéligible une valeur plus ancienne pour l’entrée qu’il vient de renvoyer. Le nom « uncacheable » décrit donc mal une règle qui organise surtout l’âge admissible d’une réponse.

Le serveur n’est pas toujours l’autorité la plus récente

Un client qui détient une délégation OPEN_DELEGATE_WRITE peut connaître une taille ou un attribut change plus récent que la copie locale du serveur. La RFC 8881 prévoit que le serveur demande ces valeurs au client par CB_GETATTR. Forcer ce client à remplacer sa connaissance plus récente par une réponse serveur plus ancienne inverserait l’autorité.

La révision 11 exclut ce résultat : l’interdiction vise une valeur plus vieille que celle que le serveur retournerait, pas la valeur plus récente du détenteur de la délégation. « Aller au serveur » ne suffit donc jamais à définir la fraîcheur. Il faut aussi savoir qui possède l’autorité d’écriture au moment de l’observation.

Même sans délégation, le READDIR ne garantit pas un présent durable. Il fournit l’état que le serveur pouvait rapporter lorsque l’entrée a été renvoyée. Une écriture peut suivre immédiatement. La nouvelle frontière réduit l’ancienneté attribuable ; elle ne crée ni gel global ni instantané atomique des données et des métadonnées.

Une propriété du chemin, pas du fichier entier

Le signal appartient au répertoire parcouru. Si le même fichier possède un lien physique dans un répertoire marqué et un autre dans un répertoire non marqué, le second chemin n’est pas soumis à cette règle. L’attribut ne se propage pas non plus automatiquement aux sous-répertoires : toute transmission relève d’une politique locale du serveur.

La gestion des types a été précisée. Comme la prise en charge d’un attribut est annoncée par système de fichiers, un GETATTR visant un objet qui n’est pas un répertoire doit renvoyer FALSE plutôt que prétendre que l’attribut est inconnu. Un SETATTR sur le mauvais type renvoie NFS4ERR_WRONG_TYPE. La capacité du système de fichiers et l’applicabilité à l’objet restent deux faits différents.

Savoir lire l’attribut ne prouve pas qu’on l’honore

Un serveur ne peut pas conclure qu’un client applique la règle parce que celui-ci a demandé ou modifié l’attribut. La requête prouve qu’il connaît le champ, non qu’il respecte sa sémantique. L’attribut demeure consultatif ; le serveur ne doit pas fonder la correction de son propre fonctionnement sur une obéissance universelle.

Les délégations de répertoire montrent pourquoi un changement de politique exige une transition. Une telle délégation autorise un client à servir l’état sans revenir au serveur. Le projet impose donc de rappeler toute délégation en cours quand l’attribut est activé et d’en refuser de nouvelles tant qu’il reste vrai. Mais le client ne voit pas nécessairement l’activation immédiatement : son cache d’attributs du répertoire doit expirer ou la revalidation doit constater le déplacement de change.

La date du réglage serveur, la date d’observation par chaque classe de clients et la première énumération conforme ne sont pas un seul horodatage.

Le coût et la limite de l’affirmation

Chaque passage supplémentaire sollicite le serveur. Un client qui choisit le chemin READDIR sans attributs puis les GETATTR individuels augmente encore la charge. Autoriser n’importe quel utilisateur à activer le signal sur un arbre très parcouru peut transformer une écriture de métadonnée en amplification de travail pour tous les clients qui l’honorent. Les droits, la politique d’export et la capacité font donc partie de la décision.

Le dossier public établit le texte, l’historique, les RFC de base, les raisons consignées dans les commits et l’existence déclarée de prototypes. Il n’établit ni version Linux livrée, ni comportement d’un produit Hammerspace, ni adoption, ni benchmark, ni incident. Le projet voisin sur les données de fichier traite du contenu et de la durabilité ; il ne change pas la portée de cette règle sur les réponses de métadonnées.

La leçon rejoint les couches de réalité de Heng Lu : le bit du serveur est une déclaration, le cache du client un état privé, READDIR une observation et stat l’affirmation reçue par l’application. La révision devient plus solide précisément parce qu’elle ne les confond plus.

Sources