Résumé

  • La valeur fattr4_uncacheable_file_data exprime le traitement demandé par le serveur ; elle ne photographie pas l’état interne d’un client.
  • Entre la modification de la valeur et son effet se trouvent la prise de connaissance par le client, l’ouverture en cours, la revalidation des lectures et la séquence qui rend une écriture durable.
  • Un registre d’exploitation crédible doit conserver séparément la décision du serveur et le reçu d’exécution du client.

Le booléen ne voyage pas instantanément

Dans un système de fichiers en réseau, le cache n’est pas un accident. C’est un compromis organisé par le protocole : rapprocher les données de l’application tout en définissant les conditions de leur réutilisation. Le projet draft-ietf-nfsv4-uncacheable-files-13 ajoute un mot qui manquait à cette conversation. Pour un fichier donné, le serveur pourra indiquer que les données ne devraient pas suivre le régime de cache ordinaire.

Le mot est utile, mais son sens se déforme facilement dans un tableau de bord. Une case vraie côté serveur peut être présentée comme si tous les clients avaient déjà vidé leur cache. Or un client doit d’abord prendre en charge l’attribut, constater que le système de fichiers exporté l’offre, lire sa valeur et l’appliquer à ses opérations. Chacune de ces étapes possède sa propre date et peut échouer indépendamment.

La situation d’un fichier déjà ouvert rend la distinction décisive. Le texte permet au client de continuer momentanément selon le comportement qui précédait la modification. Il n’est pas tenu de bouleverser aussitôt une ouverture active. La nouvelle valeur lui parvient par les mécanismes normaux de lecture d’attributs et de revalidation, puis gouverne les opérations suivantes. Une vérité administrative à 14 h 00 peut donc devenir une vérité opérationnelle à 14 h 06 sans que l’une des deux soit fausse.

Trois questions que les inventaires confondent

La première question est celle de la capacité. L’attribut numéro 87 est en lecture-écriture et figure dans la catégorie RECOMMENDED de la table NFS. Ce terme classe l’attribut ; il n’oblige pas chaque serveur NFSv4.2 à le proposer. La prise en charge appartient au système de fichiers exporté. Deux exportations sur la même machine peuvent donc répondre différemment.

La deuxième question est celle de la valeur. L’attribut vise les fichiers ordinaires et les attributs nommés. Pour un autre type d’objet, une lecture renvoie faux et une écriture échoue. Ce faux ne prouve pas que le mécanisme est disponible et que l’administrateur a choisi la mise en cache. Il peut simplement refléter le type d’objet. Un inventaire doit garder trois colonnes : type, prise en charge et valeur.

La troisième question est celle de l’autorité. Le serveur peut autoriser la modification, la refuser systématiquement ou calculer la valeur d’après une règle locale, par exemple une option appliquée aux nouveaux fichiers d’un point de montage. Les contrôles d’autorisation habituels restent en vigueur. Enregistrer seulement le dernier booléen efface la règle, l’auteur de la décision et les refus qui ont laissé l’état précédent intact.

Pour une écriture, le moment décisif est le retour à l’application

Sur le chemin d’écriture, respecter l’attribut impose au client de ne pas retarder les opérations WRITE dans le seul but de les regrouper. Mais la contrainte la plus révélatrice concerne le sens de « succès » : lorsque l’appel d’écriture revient avec succès à l’application, les données doivent être durables sur le serveur.

Le protocole autorise plusieurs séquences. Le client peut demander directement une écriture stable. Il peut aussi envoyer une écriture instable, exécuter COMMIT, puis seulement rendre la main à l’application. Si le vérificateur d’écriture fourni par le serveur a changé, les écritures touchées doivent être renvoyées à partir des données encore disponibles. La conservation temporaire nécessaire à une opération en vol n’est pas assimilée au cache que l’attribut cherche à limiter.

La preuve utile n’est donc pas « aucun octet dans la mémoire du client ». Elle relie le mode de stabilité demandé et reçu, le résultat de COMMIT, la continuité du vérificateur, une éventuelle répétition et l’heure du retour à l’application. Cette chaîne permet d’examiner une panne. Le seul booléen du serveur ne permet pas de conclure qu’une écriture acquittée particulière lui a survécu.

Une lecture fraîche n’exige pas un rituel de purge

Pour les lectures, le projet demande surtout de ne pas réutiliser les données locales sans les revalider. Le contrôle de l’attribut de changement NFS et de la taille du fichier constitue le minimum indiqué. Rien n’empêche un client d’observer davantage de métadonnées.

Cette règle prolonge le modèle de cohérence déjà décrit par NFSv4.1. L’attribut de changement compte plus qu’une supposition fondée sur le temps écoulé. Les ouvertures, réservations de partage, verrous et délégations encadrent également le cache. Une délégation peut donner au client une vue cohérente et justifier la conservation de données de lecture, même lorsque le nouvel attribut vaut vrai.

La bonne question d’audit devient alors : sur quelle preuve protocolaire le client s’est-il appuyé pour servir cette lecture ? Un reçu devrait conserver l’ancienne et la nouvelle valeur de changement, les tailles comparées, l’instant de revalidation, la délégation ou le verrou pertinent, puis le résultat : réutilisation, invalidation, nouvelle lecture ou échec. Le simple constat qu’une page mémoire existait ne tranche rien.

Deux registres reliés par l’identité de l’opération

Le registre serveur peut rester compact. Il identifie le serveur et l’exportation, confirme la disponibilité de l’attribut 87, indique le fichier, la valeur, la règle qui l’a produite, l’autorité qui pouvait la changer et l’heure d’observation. Il décrit une intention publiée.

Le reçu client a un autre objet. Il identifie l’implémentation, sa version, le montage, le fichier et l’époque d’ouverture. Il date la découverte de la valeur et précise si l’ouverture existait déjà. Pour une lecture, il joint les éléments de revalidation et le contexte de délégation. Pour une écriture, il joint stabilité, COMMIT, vérificateur, répétition et retour à l’application. Il décrit un comportement constaté.

Une identité d’opération relie les deux sans les fusionner. C’est un choix de gouvernance important. Si l’on remplace les deux horodatages par une date d’effet unique, le tableau paraît plus simple mais il devient impossible de mesurer la propagation, d’expliquer une exception ou de savoir quelle version du client a effectivement obéi.

Montrer l’adoption au lieu de la présumer

L’extension suit le mécanisme prévu par RFC 8178 pour enrichir NFSv4.2 sans invalider RFC 7862. Son caractère facultatif ne constitue pas une faiblesse à dissimuler. Il oblige simplement les exploitants à décrire leur parc tel qu’il est : exportations sans support, support disponible mais valeur fausse, valeur vraie non encore observée, valeur observée pour de nouvelles opérations, et opérations munies d’un reçu complet.

La section consacrée aux implémentations mentionne un prototype de serveur Hammerspace et un client Linux au comportement comparable à l’entrée-sortie directe pour les fichiers d’un point de montage configuré. Les gains rapportés pour certaines charges sont un signal sérieux de faisabilité. Ils ne garantissent ni la même architecture chez tous les clients, ni le même résultat économique. « Comparable » ne signifie pas « identique », et un prototype ne définit pas le parc mondial.

Cette présentation graduée est plus informative qu’un taux vert de conformité. Elle montre où la sémantique a été adoptée, où elle attend une mise à niveau, et où l’on possède une mesure plutôt qu’une simple déclaration.

La frontière de sécurité reste ailleurs

Le projet précise que l’attribut n’ajoute ni contrôle d’accès ni mécanisme d’autorisation. Il ne doit pas servir à prendre une décision de sécurité. Une personne autorisée à le modifier peut affecter les performances et la visibilité ressenties par d’autres clients ; l’identité de cette personne mérite donc d’être auditée. Mais la valeur ne devient pas pour autant un sceau d’intégrité ou une garantie contre toute donnée périmée.

La formulation publique devrait respecter cette modestie. On peut prouver qu’un serveur a demandé de limiter le cache. On peut ensuite prouver qu’un client mesuré a revalidé une lecture ou rendu une écriture durable avant d’annoncer son succès. L’attribut seul ne permet pas de réunir les deux affirmations.

Le progrès réel est précis : NFSv4.2 obtient un vocabulaire standard pour transmettre une préférence du serveur. Le reçu client transforme ensuite cette préférence en fait testable. En séparant les deux, on peut localiser les écarts sans promettre une propriété que le protocole n’a jamais prétendu fournir.

Sources