Résumé

  • Le projet NFSv4.2 approuvé par l’IESG crée un booléen par fichier qui invite les clients compatibles à supprimer la mise en cache durable des données ; sa mise en œuvre reste facultative et son effet doit être observé.
  • Une valeur true ne démontre ni qu’une ouverture existante a changé de régime, ni qu’une écriture instable a été validée, ni que les métadonnées pNFS sont visibles, ni qu’une autre application a reçu les nouveaux octets.

Un serveur pourra désormais exprimer sur le protocole un fait précis : ce fichier se prête mal à la mise en cache habituelle des données côté client. Pour les charges HPC et les fichiers modifiés en parallèle, ce signal évite de dépendre d’une modification de chaque application afin d’obtenir un comportement proche de O_DIRECT.

Il ne fait pourtant pas disparaître le cache par déclaration.

Le 17 septembre, l’IESG a approuvé Adding an Uncacheable File Data Attribute to NFSv4.2 et l’a transmis à la file du RFC Editor. La révision 16 définit fattr4_uncacheable_file_data, attribut 87, comme un booléen lisible et modifiable pour les fichiers ordinaires et les attributs nommés. Le mot RECOMMENDED désigne ici une catégorie NFS : il n’oblige pas tous les serveurs à l’implémenter.

Le support se décide par système de fichiers exporté. Deux exports servis par la même machine peuvent donc diverger. Le client consulte supported_attrs ou effectue une sonde. Un SETATTR adressé à un export qui ignore le champ échoue avec NFS4ERR_ATTRNOTSUPP, tandis qu’un GETATTR omet simplement le champ. L’absence ne fournit pas, à elle seule, une conclusion exploitable.

Lorsqu’il respecte la valeur vraie, le client ne doit pas retarder la transmission d’un WRITE dans le seul but de regrouper des opérations ou de gagner en efficacité. La règle vise un danger concret : deux clients peuvent modifier des zones distinctes d’un même bloc et l’un d’eux réécrire une copie périmée par-dessus le travail de l’autre. Envoyer rapidement réduit cette fenêtre de corruption.

La durabilité relève d’une autre preuve. L’attribut ne fixe pas stable_how4. Le projet impose plutôt un invariant : lorsque l’appel d’écriture de l’application se termine avec succès, les données doivent être durables sur le serveur. FILE_SYNC4 et DATA_SYNC4 peuvent produire cette propriété avec la réponse au WRITE. Avec UNSTABLE4, un COMMIT doit finir avant le retour à l’application ; si le vérificateur d’écriture a changé, le client réémet les WRITEs concernés tant que le tampon applicatif existe encore.

Conserver provisoirement les octets nécessaires à cet échange n’est donc pas la mise en cache durable visée par l’attribut. À l’inverse, le bit ne pardonne pas un COMMIT manquant. « Non cacheable » décrit la politique du cache de données, pas un reçu de persistance déjà acquis.

La lecture ajoute son propre chemin. Un client qui garde des données ne devrait pas les réutiliser avant d’avoir revalidé l’attribut de changement et la taille du fichier. Une délégation peut, dans certains cas, fournir une autre vue cohérente. En pNFS, l’attribut vient du serveur de métadonnées, alors que les octets circulent parfois directement vers des périphériques de stockage. Durabilité des octets et visibilité des métadonnées ne sont pas le même événement. Si le layout requiert LAYOUTCOMMIT, son retard peut laisser un autre client observer les anciennes métadonnées.

Le temps empêche également de résumer l’état à un booléen. Si la valeur change pendant qu’un fichier est ouvert, le client peut conserver le choix de cache fait à l’OPEN jusqu’à la fin de cette ouverture. Expiration du cache d’attributs, revalidation et OPEN ultérieur bornent l’adoption. Le true lu aujourd’hui ne décrit pas automatiquement les ouvertures d’hier.

Le texte reste tout aussi étroit sur le pouvoir. La politique du serveur décide si un demandeur peut positionner ou effacer le champ. L’extension n’ajoute aucune authentification, ne change aucun contrôle d’accès et ne crée aucune frontière de sécurité. Elle ne remplace ni les mécanismes de cohérence ni les protections d’intégrité de NFSv4.2.

La révision 16 mentionne un prototype de serveur Hammerspace et un prototype de client Linux, avec des bénéfices observés pour des E/S bien formées. C’est une preuve de faisabilité, non une mesure de déploiement général, d’activation par défaut, d’interopérabilité ou de gain universel. Le projet demande lui-même de comparer le fonctionnement réel avec et sans attribut sur un client qui le respecte effectivement.

Le registre opérationnel doit donc conserver séparément la révision de la spécification, le support de l’export, la politique du serveur, la valeur vue par un client nommé, l’époque de l’OPEN, la version du client, le mode de stabilité du WRITE, le vérificateur et le COMMIT, l’éventuel LAYOUTCOMMIT, la revalidation de lecture et le résultat visible par l’application. Le bit ouvre cette chaîne ; il ne la ferme pas.

Sources