Résumé

  • Un chemin NFS sert à retrouver un fichier ; les opérations suivantes emploient un repère opaque émis par le serveur. Le client le conserve sans pouvoir y lire un numéro d’inode, une adresse de disque ou une identité universelle.
  • NFSv4 distingue les repères persistants, stables pendant la vie de l’objet malgré un redémarrage ou une migration, et les repères volatils, dont les conditions d’expiration doivent être annoncées.
  • NFS4ERR_STALE signifie que la référence n’atteint plus un objet présent ou disponible. NFS4ERR_FHEXPIRED peut signaler la fin d’un repère temporaire alors que le fichier existe encore. Retrouver le nom constitue une nouvelle résolution, jamais une interprétation des anciens octets.

Deux noms, un seul fichier

Un répertoire contient bilan, un autre nom pointe par lien physique vers le même fichier, puis l’un des deux noms change. Quel est l’objet ? Le chemin répond à la question « comment y parvenir maintenant ». Il ne garantit pas, à lui seul, la continuité de l’objet entre deux requêtes.

NFS avait besoin d’une référence que le serveur puisse reconnaître après la recherche. Dans la version 2 décrite par le RFC 1094 en 1989, le client partait d’un repère racine obtenu via le protocole de montage, présentait à LOOKUP le repère d’un répertoire et le nom d’un composant, puis recevait le repère suivant. READ, WRITE ou GETATTR ne renvoyaient pas tout le chemin : ils utilisaient la référence obtenue.

Cette référence mesurait exactement 32 octets et était dite opaque. L’adjectif n’annonçait ni chiffrement ni secret. Il retirait au client le droit de déduire une structure interne. Même si un serveur y plaçait des informations ressemblant à un périphérique, un inode ou une entrée de table, ce choix ne devenait pas une convention NFS.

Le RFC 1813 a rendu variable la taille du repère de NFSv3. Le type nfs_fh3 devait transporter ce dont le serveur avait besoin pour distinguer un fichier. Les opérations de création et de parcours pouvaient le rendre au client. Le serveur conservait ainsi la maîtrise de sa représentation ; le client obtenait une référence réutilisable, pas la carte de l’intérieur du serveur.

Le test d’égalité ne fabrique pas une identité globale

Deux repères identiques, reçus du même serveur, désignent le même fichier. Cette règle est utile à un cache. Mais sa réciproque est fausse : deux suites d’octets différentes peuvent encore conduire au même objet. Le RFC 1813 précise qu’une correspondance bijective n’est pas exigée et que la comparaison sert aux performances, non à la correction du protocole.

NFSv4 maintient cette prudence. Deux noms liés physiquement devraient fournir le même repère, mais un client ne peut pas classer l’ensemble des objets à partir de la seule inégalité des valeurs. Il ne peut pas davantage comparer sans contexte des repères issus de serveurs distincts. Le domaine d’identité reste celui du serveur qui les a émis.

Cette limite protège une possibilité essentielle : le serveur peut changer son organisation sans faire des détails de son système de fichiers une API durable. Le prix est une dépendance. Puisque le client ne peut pas réparer ou interpréter la référence, le protocole doit lui dire quand elle cesse d’être fiable.

De l’opacité à une promesse de durée

NFSv4 a formulé cette durée. Le RFC 3010 a séparé les repères persistants des repères volatils ; les RFC 7530 et 8881 ont conservé cette architecture.

Un repère persistant reste fixe pendant la vie de l’objet. Le redémarrage du serveur ne doit pas le rendre invalide. La migration de l’objet ne doit pas obliger le client à adopter arbitrairement une autre identité. Le serveur peut réorganiser son stockage tout en maintenant le contrat visible.

« Persistant » ne veut pas dire éternel. Un fichier supprimé n’a plus d’objet auquel renvoyer. Un système de fichiers devenu indisponible ne peut plus honorer la référence. Dans ces cas, le serveur répond NFS4ERR_STALE. Surtout, il ne recycle pas silencieusement l’ancien repère pour l’objet qui occuperait ensuite la même place interne.

Tous les environnements ne savent pas assurer cette invariance. Une hiérarchie de stockage, une migration, les limites d’un système d’exploitation ou une table reconstruite au démarrage peuvent interrompre le lien. NFSv4 autorise alors des repères volatils. Avec fh_expire_type, le serveur expose les circonstances dans lesquelles ils peuvent cesser de fonctionner.

Les RFC proposent, à titre d’illustration, un repère contenant une heure de démarrage, une case de table et une génération. Une ancienne génération révèle la réutilisation d’une case. Ce n’est pas un format obligatoire. Ce que le standardise l’IETF, c’est le comportement observable : le serveur doit annoncer la volatilité et reconnaître la rupture.

Périmé ou expiré : deux constats différents

NFS4ERR_STALE correspond à une référence dont l’objet a été supprimé ou dont le système de fichiers n’est plus disponible. Le constat porte sur l’impossibilité d’atteindre le référent attendu.

NFS4ERR_FHEXPIRED porte sur le repère. Un redémarrage peut avoir effacé la table qui lui donnait sens ; une génération peut avoir changé ; une migration peut dépasser ce que ce type de repère promettait. L’objet sous-jacent peut toutefois subsister. Le serveur refuse les anciens octets sans prétendre connaître une suppression.

La nuance évite deux mensonges opérationnels. Assimiler toute expiration à une disparition transformerait un défaut de continuité en perte de données. Assimiler toute référence périmée à un incident temporaire encouragerait des tentatives sans fin sur un fichier détruit. Les erreurs ne résolvent pas l’incertitude ; elles la localisent correctement.

Repartir de la racine, sans revenir dans le passé

NFSv4 fournit des repères spéciaux de racine et des opérations de parcours. PUTROOTFH choisit la racine courante ; des LOOKUP successifs retrouvent les composants. Le même mécanisme sert à récupérer d’une expiration si le client a gardé le chemin.

Mais retrouver un nom ne ressuscite pas l’ancien repère. Entre-temps, un autre acteur peut avoir renommé ou supprimé le fichier. Le nom peut désormais conduire à un remplaçant. Le client vient d’effectuer une nouvelle observation et doit vérifier l’identité et l’état dont dépendait son travail.

La prudence est décisive pour une écriture interrompue, un verrou ou des attributs mis en cache. Résoudre à nouveau le chemin ne prouve pas que l’opération peut être rejouée. Et détenir un repère valide ne confère aucun droit : le serveur contrôle séparément l’autorisation de lire, d’écrire ou de modifier.

L’histoire du repère NFS est donc celle d’une référence volontairement limitée. Le serveur décide de la représentation et répond de sa continuité. Le standard impose un noyau commun : opacité, égalité bornée, classe de durée et échec explicite. Le client garde de quoi refaire le parcours et accepte de perdre une continuité qu’il ne peut plus prouver.

Un chemin peut changer sans que le fichier change. Le fichier peut survivre à l’expiration de son repère. Le repère peut être valide sans autoriser l’opération. L’interopérabilité tient à cette séparation, pas à un identifiant qui prétendrait tout dire.

Sources