Résumé

  • NFSv2 liait le retour d’une écriture à son arrivée en stockage stable ; cette sécurité simplifiait la reprise d’un serveur sans état, mais plaçait la latence du support durable sur chaque appel.
  • NFSv3 sépara la réussite de l’appel et le niveau d’engagement : UNSTABLE, DATA_SYNC ou FILE_SYNC. Le résultat indiquait le nombre réellement écrit, le niveau obtenu et un vérificateur opaque.
  • Tant qu’un COMMIT ou une écriture plus forte n’avait pas établi la durabilité, le client gardait les octets. Si le vérificateur changeait, il devait supposer les données instables perdues et les réémettre.

Le succès qui ne permettait pas encore d’oublier

Prenons un bloc de fichier envoyé à une machine distante. Le RPC revient avec NFS3_OK. Dans beaucoup d’interfaces, ce mot succès invite aussitôt l’appelant à jeter sa copie. Or le résultat NFSv3 peut aussi porter committed = UNSTABLE. L’opération réseau a abouti, le serveur a accepté des octets, mais la preuve ne dit pas encore qu’ils survivront à la disparition de sa mémoire volatile.

Cette distinction répondait à un coût historique. Le RFC 1094, qui décrit NFS version 2 en 1989, faisait des opérations modificatrices des opérations synchrones. Au retour d’une écriture, le client pouvait considérer les données sur stockage stable et les abandonner. Cette règle convenait à l’idéal du serveur sans état : après une panne, le client répétait une requête au lieu de reconstruire une longue session. Mais chaque écriture attendait aussi le chemin de persistance.

Le RFC 1813 nomme cette attente un goulet d’étranglement de débit. NFSv3 introduit donc les « écritures asynchrones sûres ». L’adjectif sûr ne signifie pas que chaque réponse est déjà durable. Il signifie que le protocole conserve les informations et la copie nécessaires pour achever ou recommencer le travail.

Trois degrés au lieu d’un booléen trompeur

Dans la requête WRITE, le champ stable peut demander UNSTABLE, DATA_SYNC ou FILE_SYNC. FILE_SYNC exige que les données et toutes les métadonnées du fichier aient atteint le stockage stable avant la réponse. DATA_SYNC exige les données et assez de métadonnées pour les retrouver. UNSTABLE autorise le serveur à avoir persisté tout, une partie ou rien.

Le serveur ne recopie pas simplement la préférence du client. Sa réponse contient committed, c’est-à-dire le niveau effectivement obtenu. Un serveur équipé d’un support non volatil rapide peut rendre FILE_SYNC même si le client avait demandé moins. À l’inverse, il ne peut pas annoncer un niveau inférieur à celui demandé. L’autorité de la réponse réside donc dans ce champ précis, pas dans la couleur générale de NFS3_OK.

Le résultat contient aussi count. Un serveur peut effectuer une écriture courte. La réussite porte alors sur les octets comptés, et le client doit envoyer le reste. Avant même de parler de durabilité, il faut donc poser une première question : quelle plage a réellement été acceptée ? La seconde vient ensuite : à quel niveau cette plage est-elle engagée ?

Cette structure empêche trois propositions de se fondre en une seule : le RPC a reçu une réponse ; un certain nombre d’octets ont été traités ; ces octets sont durables. Elles peuvent toutes devenir vraies, mais pas nécessairement au même moment.

Le cookie ne décrivait pas le fichier

La dernière pièce du résultat est verf, le write verifier. C’est un cookie opaque. Il doit rester constant pendant une instance pertinente du service et changer entre les instances où des données non engagées peuvent avoir disparu. Le cas courant est le redémarrage du serveur, mais la règle vise l’événement qui détruit la garde volatile, pas seulement un bouton d’alimentation.

Le vérificateur n’est pas une empreinte du contenu. Deux écritures différentes peuvent partager sa valeur parce qu’elles appartiennent à la même instance. Une valeur identique ne prouve ni que le fichier est inchangé, ni que tous les octets demandés furent écrits, ni qu’un autre client n’a rien modifié. Elle répond à une question plus étroite : peut-on encore relier l’ancienne garde instable à la même incarnation du serveur ?

Après une réponse instable, le client garde donc son tampon dans un état intermédiaire. Le RFC décrit trois états : sale ; terminé mais à engager ; terminé. Cette mémoire cliente est le prix réel de la réponse rapide. Le serveur gagne la liberté de grouper les écritures physiques ; le client accepte de ne pas oublier avant d’avoir une preuve plus forte.

COMMIT fermait la dette, sous condition

L’opération COMMIT demande au serveur de pousser vers le stockage stable les données précédemment écrites de façon instable. Elle peut viser une plage. Un offset de zéro et un compte de zéro couvrent le fichier depuis son début jusqu’à sa fin. La comparaison avec fsync aide, mais elle ne doit pas devenir une équivalence absolue : COMMIT reste une opération distante, portant sur un fichier et les obligations définies par NFS.

Une réussite renvoie à nouveau un vérificateur. S’il correspond à celui des écritures, le client peut rattacher l’engagement au même monde qui avait gardé ses octets. S’il diffère, l’ancienne mémoire ne possède plus d’autorité. Le client doit considérer les plages anciennement UNSTABLE comme possiblement perdues et les retransmettre.

« Possiblement » est essentiel. Un changement ne prouve pas que chaque octet a disparu ; certains ont pu atteindre le disque avant la panne. Mais le client ne peut plus distinguer sûrement lesquels. Le choix prudent est de réémettre des écritures idempotentes aux offsets connus. Le protocole transforme ainsi l’incertitude en règle de récupération, sans inventer une observation qu’il ne possède pas.

La symétrie inverse compte aussi. Un vérificateur inchangé n’est pas un reçu de contenu. Il rend seulement légitime la comparaison entre les étapes. Il faut encore le statut du COMMIT, les plages, les comptes et, pour la cohérence avec d’autres écrivains, des mécanismes supplémentaires.

Ce que « stockage stable » promettait — et ce qu’il laissait dehors

RFC 1813 décrit un stockage persistant à travers des coupures électriques répétées, des défaillances matérielles ordinaires et des cycles de panne logicielle et de redémarrage. Il précise aussi que cette définition ne couvre pas la panne du module de stockage stable lui-même. La durabilité n’est donc ni une sauvegarde, ni une réplication, ni une permanence métaphysique.

Le même document refuse de promettre une cohérence stricte entre caches client et serveur, ou entre plusieurs clients. Un COMMIT peut établir la persistance d’une plage sans dire qu’une application a choisi la bonne version, qu’aucune écriture concurrente n’a eu lieu ou que le fichier complet satisfait son format. NFS bornait une responsabilité de stockage ; il ne réglait pas tout le système distribué.

Les générations suivantes ont conservé cette leçon. Le RFC 3530, puis le RFC 7530, maintiennent le couple écriture instable–COMMIT dans NFSv4. Le RFC 8881 formule explicitement la conséquence : si le vérificateur change, le client doit présumer perdues les données rendues avec l’ancien vérificateur et un engagement instable. Le protocole devint plus riche en état, mais cette frontière de preuve resta utile.

Une réussite découpée pour rester honnête

L’histoire de NFSv3 n’est pas celle d’un système qui aurait sacrifié la sécurité à la vitesse. C’est celle d’un protocole qui a refusé de cacher le sacrifice temporaire. Il a permis au serveur de répondre plus tôt, nommé le degré de persistance, laissé le serveur annoncer un résultat plus fort, obligé le client à garder une copie et fourni un indice de rupture d’incarnation.

La performance provenait donc d’un déplacement de travail, pas de sa disparition. Les attentes de support durable pouvaient être regroupées. En échange, le client devait financer des tampons, suivre des plages et supporter une rafale de réécritures après changement du vérificateur. Un système qui ne dimensionne que le chemin normal emprunte de la capacité à son propre chemin de reprise.