Résumé

  • L’opération LAYOUT_WCC transporte vers le serveur de métadonnées des attributs que le client a déjà reçus après une opération NFSv3 sur un fichier de données.
  • Le serveur peut économiser un GETATTR, ignorer le rapport ou contrôler directement l’état ; le succès de l’opération ne détaille pas les attributs qu’il a retenus.
  • Taille, horodatages et propriétaire décrivent un état observé, mais ne prouvent ni l’écriture stable, ni l’identité de tous les miroirs, ni le résultat vu par l’application.

Un système distribué paie souvent deux fois la même observation. Dans un agencement pNFS flexible, le client écrit directement sur un serveur de données et reçoit, dans la réponse NFSv3, des attributs postérieurs à l’opération. Plus tard, le serveur de métadonnées peut interroger ce même serveur pour retrouver une information que le client possède déjà. RFC 9766 propose de faire circuler cette observation au lieu de la jeter.

Le gain potentiel réside dans un trajet évité. La question institutionnelle est de savoir qui décide que l’observation suffit. La réponse du RFC est volontairement sobre : le client rapporte, le serveur de métadonnées décide. Le raccourci réduit une dépense sans transférer la souveraineté sur l’état du fichier.

Deux plans de contrôle pour un seul fichier

pNFS sépare le chemin des données du chemin des métadonnées. Le serveur de métadonnées conserve l’espace de noms, distribue et rappelle les layouts, et reste capable de servir lui-même les entrées-sorties. Un layout peut cependant envoyer le client vers des serveurs de données. Dans le flexible file layout, ces serveurs peuvent parler NFSv3.

Cette architecture ouvre une fenêtre de visibilité. Lorsqu’un client modifie directement un fichier de données, aucune notification générale de NFSv3 n’impose au serveur de données d’avertir aussitôt le serveur de métadonnées. Les octets et certains attributs peuvent avoir évolué sur le premier plan alors que le second doit répondre à une nouvelle demande.

Le serveur de métadonnées dispose déjà d’une voie forte : lancer GETATTR vers le serveur de données. Il récupère alors une vue actuelle et peut comparer taille, espace utilisé ou horodatages. Mais la vérification directe ajoute une requête. À l’échelle, une succession d’interrogations de métadonnées peut reporter une part sensible du coût vers le stockage. Après une écriture, NFSv3 exige en outre une opération distincte là où une opération composée de NFSv4 peut associer écriture et lecture d’attributs.

L’opération 77 de NFSv4.2, LAYOUT_WCC, exploite le reçu déjà présent chez le client. Les réponses à READ, WRITE et COMMIT en NFSv3 peuvent contenir des données de Weak Cache Consistency. Le client convertit ces champs vers leurs équivalents NFSv4.2 et les adresse au serveur de métadonnées.

Le mot « faible » fixe la portée de la preuve

WCC n’est pas une promesse diminuée par accident. RFC 1813 la définit autour de certains attributs avant l’opération et des attributs après l’opération. Cette paire aide un client à déterminer si un autre changement a pu intervenir et s’il doit invalider son cache. Elle fournit davantage de contexte qu’un instantané isolé.

Elle n’offre pourtant pas une cohérence stricte. Pour la forme la plus probante, l’état préalable, l’opération modificatrice et l’état postérieur doivent être traités atomiquement. Si un autre acteur intervient dans cette fenêtre, une partie de l’histoire disparaît. Même correctement obtenu, le résultat porte sur quelques attributs autour d’une opération donnée ; il ne verrouille pas les écritures ultérieures.

RFC 9766 conserve cette fragilité comme propriété visible du mécanisme. Le serveur de métadonnées peut juger le rapport assez frais pour répondre sans nouvelle sonde. Il peut également exécuter GETATTR si l’âge, un conflit ou la conséquence de la décision exige une preuve plus forte. Le protocole standardise le message, pas l’appétit local pour le risque.

La liberté existe des deux côtés. Le client peut ne pas utiliser les informations WCC reçues. Le serveur peut écarter les attributs du rapport. Puisque le client ne dispose d’aucun recours lorsque le serveur les ignore, la réponse ne contient pas de bitmap indiquant les champs acceptés. Un succès RPC ne constitue donc pas un reçu d’adoption champ par champ.

Huit attributs, plusieurs significations possibles

Pour le flexible file layout, huit attributs NFSv3 sont mappés : size, space_used, mode, owner, owner_group, time_access, time_modify et time_metadata. Les uid et gid numériques deviennent les chaînes utilisées par les champs de propriétaire de NFSv4.

Cette liste mêle capacité, temporalité et données proches de l’autorisation. Une taille accrue est compatible avec une écriture, sans en démontrer l’origine. Un accès plus récent est compatible avec une lecture, sans dire quel consommateur l’a déclenchée. Un désaccord de mode ou de propriétaire peut éclairer une erreur d’accès, sans indiquer automatiquement quel côté doit être corrigé.

Le RFC cite des usages où la remontée peut éviter une seconde lecture : avant une demande de taille, d’espace consommé, d’attribut de changement ou d’horodatage ; lors du signalement de NFS4ERR_ACCESS, afin de comparer les uid/gid attendus et constatés ; ou lorsque le client actualise les temps d’accès et de modification sous une délégation appropriée.

Ce sont des points de décision, pas des ordres de réparation. Face à une divergence de propriétaire, le serveur de métadonnées peut découvrir un état de stockage périmé, un layout dépassé ou sa propre attente obsolète. Déclencher aveuglément SETATTR transformerait une pièce de diagnostic en autorisation d’écrire.

Une position dans une liste n’est pas une identité

Le rapport se rattache d’abord au fichier courant et au layout grâce au filehandle et à lowa_stateid; lowa_type détermine l’interprétation de la charge opaque. Dans un flexible file layout, celle-ci peut décrire les miroirs et les serveurs de données qui les composent.

La structure en tableaux invite à parler du « deuxième miroir » ou du « premier serveur ». Le RFC refuse cette facilité. Le client peut transmettre les trois miroirs et laisser un masque vide pour celui qui n’a pas changé ; il peut aussi ne transmettre que les deux miroirs concernés. La position varie donc avec l’omission. Le serveur doit reconnaître un fichier de données par le triplet device ID, stateid et filehandle. Ces trois éléments sont nécessaires puisqu’un même dispositif peut contenir plusieurs fichiers d’un layout.

Ce détail illustre une règle de preuve plus générale : la proximité n’est pas l’identité. Un reçu réutilisable nomme l’objet par des attributs qui résistent au réordonnancement et à la sélection partielle.

Le traitement des erreurs renforce la même exigence. En cas d’erreur autorisée, le serveur de métadonnées peut ignorer toute l’opération ou, si le type de layout le permet, appliquer une partie de la charge. Une trace d’audit utile doit donc conserver le fichier identifié, le masque reçu et les champs effectivement utilisés. Le seul code de retour ne permet pas de reconstituer une décision partielle.

Le rapport ne remplace aucun reçu voisin

La taille ou time_modify peuvent donner l’impression que les données sont en sécurité. Elles ne valent pas accusé d’écriture stable. Le flexible file layout impose séparément au client de stabiliser par COMMIT les écritures instables avant LAYOUTCOMMIT lorsqu’une écriture n’a pas retourné FILE_SYNC. LAYOUT_WCC ne fusionne pas ces étapes.

Un rapport isolé ne démontre pas davantage l’accord des miroirs. Dans le mirroring côté client décrit par RFC 8435, le client doit mettre à jour toutes les copies et la transaction d’écriture n’est réussie que si chacune l’est. Une erreur peut être signalée au serveur de métadonnées pour qu’un miroir soit réparé. Les attributs d’un fichier de données ne parlent pas pour des copies que l’opération n’a pas observées.

Enfin, le système de fichiers n’est pas l’application. Des métadonnées exactes peuvent coexister avec des octets périmés dans un cache applicatif. Des copies identiques peuvent contenir le mauvais fichier demandé. L’état observé, la durabilité, la convergence des répliques et l’usage métier exigent des reçus distincts.

L’optionnalité protège le chemin de repli

L’opération est optionnelle pour NFSv4.2 et pour le flexible file layout. Ce choix permet à deux versions de progresser indépendamment. Un endpoint dépourvu de l’opération 77 peut rester interopérable grâce aux mécanismes antérieurs, notamment la vérification directe. Il risque de faire davantage de travail ; son absence ne le rend pas automatiquement invalide.

RFC 8178 encadre l’extension de NFSv4, tandis que RFC 7862 et RFC 7863 fournissent le protocole NFSv4.2 et son XDR. Ces textes prouvent la syntaxe et le statut normatif du mécanisme. Seuls des endpoints en fonctionnement peuvent prouver qu’ils l’ont négocié et exercé.

La sécurité reste celle du flexible file layout. En couplage lâche, des uid/gid synthétiques peuvent tenir à distance des clients coopératifs, mais ne neutralisent pas nécessairement un client malveillant ni un client particulier. Le couplage fort dépend de son protocole de contrôle. Les communications de fond doivent être protégées contre l’observation et l’altération. Authentifier le client établit l’émetteur du rapport dans ce canal ; cela ne garantit pas que chaque champ représente le dernier état du serveur de données.

Sources

  1. RFC 9766 : Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435 : Parallel NFS Flexible File Layout
  3. RFC 8434 : Requirements for pNFS Layout Types
  4. RFC 1813 : NFS Version 3 Protocol
  5. RFC 8881 : NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862 : NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863 : NFSv4.2 XDR Description
  8. RFC 8178 : Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754 : Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile