Résumé

  • RFC 9737 ouvre, pendant la période de grâce, un canal LAYOUTRETURN utilisant le stateid anonyme tout à zéro pour transmettre les erreurs d’E/S observées durant l’arrêt du MDS.
  • Un fichier réclamé sans erreur ne doit pas être reconstruit ; une erreur déclarée ou l’absence de récupération impose au contraire un resilvering, mais pour des raisons différentes.
  • Le message admis ne prouve ni la vérité complète du miroir choisi, ni la réussite de la copie, ni la validité des données pour l’application.

Le serveur de métadonnées revient. Un client reprend son fichier et ne déclare aucune erreur. Un autre client ne revient pas du tout. Dans un tableau de bord sommaire, les deux lignes portent le même chiffre : zéro erreur.

Pour le protocole, elles n’ont pas le même sens.

Le premier silence est attaché à une action positive : le client a réclamé l’état qu’il détenait avant le redémarrage. Le second est une absence de témoin. Le client peut avoir redémarré, perdu son état local ou cessé de répondre. RFC 9737 fait de cette différence la frontière entre « ne pas reconstruire » et « reconstruire par prudence ».

Le témoin des écritures est le client

Dans un déploiement pNFS à flexible file layout, le serveur de métadonnées fournit une disposition, puis le client accède directement aux serveurs de données. Quand les données sont répliquées côté client, celui-ci doit envoyer l’écriture à chaque miroir. Il est donc le premier acteur capable de constater qu’un appareil ou une plage d’octets n’a pas accepté l’opération.

RFC 8435 encode ce constat dans ff_ioerr4 : identifiant du dispositif, opération, état d’erreur, offset et longueur. Le texte qualifie ces indications de hints adressés au MDS. Elles sont suffisamment structurées pour guider une décision ; elles ne deviennent pas pour autant une attestation exhaustive de l’intégrité du fichier.

Le redémarrage du MDS détruit la voie normale de transmission. Les anciens layout stateids ne sont plus valides. La période de grâce autorise la récupération de l’état ouvert par CLAIM_PREVIOUS, mais pas la fabrication d’un nouveau layout simplement pour raconter une erreur survenue sous l’ancien.

RFC 9737 autorise donc le client à utiliser le stateid anonyme composé uniquement de zéros dans LAYOUTRETURN. La valeur n’accorde pas un nouveau droit d’écriture. Elle rend un témoignage recevable dans une fenêtre précise.

Un silence accompagné d’une récupération est une preuve négative bornée

Le tableau de décision est strict. Si le client récupère le fichier et ne signale pas d’erreur, le MDS ne doit pas lancer de resilvering. Si une erreur est signalée, le fichier doit être reconstruit. Si aucun reclaim ni aucun rapport n’arrive avant la fin de grâce, le MDS doit également reconstruire.

Le dernier cas protège contre une erreur de logique courante : considérer l’absence de message comme un message vide. Un client mort ne peut pas certifier que tous les miroirs ont accepté ses écritures. Sa disparition retire une source d’information ; elle ne crée pas un résultat favorable.

Même le reclaim propre reste borné. Il signifie que ce client n’a pas rencontré d’erreur à déclarer dans le chemin défini. Il ne prouve pas qu’un bit n’a jamais changé sur le média, qu’un autre client n’a rien observé, que le contenu respecte la logique métier ou que toutes les lectures futures seront correctes.

La discipline opérationnelle exige de conserver le verbe exact : observé, récupéré, déclaré, accepté, reconstruit, vérifié. Remplacer toute la chaîne par « sain » fait disparaître la réalité que le protocole avait précisément séparée.

Le zéro n’a de sens qu’à l’intérieur de la grâce

Pendant la grâce, un stateid non nul dans ce LAYOUTRETURN reçoit NFS4ERR_GRACE. Après la grâce, le stateid nul reçoit NFS4ERR_NO_GRACE. Le même champ change donc de recevabilité avec l’époque de récupération.

Cette limite empêche la petite exception de devenir une autorité durable. Le MDS ne doit pas non plus incrémenter le seqid du stateid de résultat lorsqu’il traite cette forme anonyme. Le rapport intervient dans la décision sans feindre une transition ordinaire d’un layout vivant.

Une preuve d’exploitation doit relier la valeur zéro au redémarrage précis, à l’intervalle de grâce, au fichier, au client, au write intent, au jeu de miroirs et à la réponse du serveur. Une capture qui montre seulement seize octets nuls ne démontre pas que l’usage était valable.

Une observation exacte peut viser une configuration qui n’existe plus

Le MDS compare ensuite le layout retourné aux instances de miroir actuelles. Si l’ensemble diffère, il doit ignorer le rapport et reconstruire. Le client peut avoir décrit fidèlement l’ancienne topologie ; cette fidélité ne suffit pas pour décider sur la nouvelle.

Cette règle sépare la qualité du témoin de la correspondance de configuration. Une erreur exacte sur le miroir B n’aide pas si le MDS considère désormais A, C et D. La trace opérationnelle doit donc conserver les deux empreintes de topologie et la conclusion de comparaison.

Sans elles, un rapport accepté au niveau transport peut être présenté à tort comme la cause du choix de reconstruction. Le MDS a peut-être pris la voie prudente parce que le rapport était devenu inapplicable.

La reconstruction commence après la décision

Lorsqu’un resilvering est nécessaire, RFC 9737 décrit un ordre général : fence du fichier, enregistrement de l’intention de reconstruire, libération du write intent, puis démarrage lorsqu’aucun write intent ne subsiste. Le MDS ne doit pas copier pendant qu’un client possède encore cette autorité d’écriture.

Le mode de service pendant la copie reste local. Le MDS peut bloquer les E/S, les faire passer par lui ou insérer un proxy chargé d’actualiser la nouvelle copie. Ce choix ne modifie pas la responsabilité : le serveur de métadonnées doit reconstruire et maintenir la cohérence des miroirs.

Une réponse LAYOUTRETURN n’est donc que le début d’un nouveau faisceau de preuves : source choisie, fence effective, copie des plages, convergence, lecture postérieure et validation applicative. Le rapport dit où regarder. Il ne remplace pas le contrôle du résultat.

L’ancienne version paie la prudence

Si le client envoie le stateid nul à un MDS qui ne connaît pas l’extension, il reçoit NFS4ERR_BAD_STATEID et doit revenir à l’ancien comportement, sans transmettre l’erreur par ce chemin. Le système ne prétend pas que deux versions se comprennent.

Le repli est sûr mais coûteux. Faute d’un témoignage exploitable, le MDS conserve sa décision conservatrice de reconstruction. Il dépense du temps, de la bande passante et des IOPS pour ne pas inventer une certitude.

La direction doit donc mesurer l’économie réelle de l’extension : combien de rapports admis ont évité des copies inutiles, combien de clients sont restés silencieux, combien de topologies ont divergé, combien de replis ont produit un resilvering prudent. La valeur de RFC 9737 ne vient pas d’un stateid magique. Elle vient d’une meilleure comptabilité de ce qui est connu, de ce qui manque et de ce qui a cessé d’être applicable.

Sources