Résumé

  • La déclaration de fin de récupération ferme les revendications restantes du client dans son périmètre. Ce n'est pas une instruction permettant au serveur de supprimer le délai des autres clients.
  • Même après cette déclaration, une demande de nouveau verrou peut recevoir une erreur de grâce. L'admission dépend aussi des récupérations encore possibles.
  • Une partition du réseau suivie d'un redémarrage peut faire réapparaître une ancienne revendication dont la continuité a été rompue. Sans historique stable suffisant, le refus conservateur reste nécessaire.

Celui qui attend après avoir fini

Un client a rétabli ses ouvertures et ses verrous après le redémarrage d'un serveur de fichiers. Il annonce la fin de cette récupération, puis demande un nouveau verrou. Le serveur lui répond qu'il est encore en période de grâce. Pour une équipe qui résume la reprise à un indicateur unique, cette attente semble incohérente : pourquoi bloquer celui qui a déjà terminé ?

Parce que sa déclaration ne concerne pas les absents. Un autre client peut encore revenir avec des droits antérieurs qu'une nouvelle attribution rendrait incompatibles. Le premier sait ce qu'il a récupéré ; il ne sait pas ce que le second doit encore récupérer.

Ce cas est une illustration du protocole, pas le récit d'un incident observé. Il permet de lire les sections 8.4, 9.11 et 18.51 du RFC 8881 comme une répartition précise des responsabilités. Le client termine sa récupération. Le serveur décide quelles nouvelles demandes sont admissibles. Les deux décisions ne deviennent pas nécessairement possibles au même instant.

Deux usages d'un verrou

Lorsqu'un serveur a perdu son état de verrouillage, il doit laisser aux clients la possibilité de reconstituer leurs droits antérieurs sans qu'une attribution nouvelle et conflictuelle les devance. La grâce protège cette possibilité. Elle n'est pas une simple pause destinée à laisser les machines se remettre en route.

La récupération d'une ouverture existante passe par OPEN avec CLAIM_PREVIOUS, en utilisant le descripteur de fichier courant de la cible. Elle ne consiste pas à ouvrir un nouveau nom dans un répertoire. Pour un verrou de plage d'octets, l'opération LOCK indique explicitement qu'il s'agit d'une récupération.

Cette différence n'accorde aucun passe-droit. Les règles ordinaires d'accès et les conflits restent applicables. Présenter une demande comme ancienne ne permet pas d'obtenir une autorisation que le demandeur n'a pas.

La période de grâce n'interdit pas non plus toute activité. Les clients doivent pouvoir établir l'identité et la session nécessaires à leur retour. Le serveur peut autoriser des opérations nouvelles lorsqu'il dispose d'informations suffisantes pour exclure un conflit avec une récupération ultérieure. Pour les lectures et écritures aussi, la question est celle de cette compatibilité, non celle d'un arrêt automatique de toutes les entrées-sorties.

Une table de verrous actuellement vide ne répond pas à la question. Si un client n'a pas encore pu transmettre ses demandes, cette absence est précisément ce que la table ne montre pas.

Une fin qui engage le déclarant

La forme globale de RECLAIM_COMPLETE utilise rca_one_fs à faux. Après l'établissement d'un nouvel identifiant client, cette déclaration est nécessaire avant la première demande de nouveau verrou, même lorsqu'il n'existe aucun ancien verrou à récupérer.

Son effet dépasse celui d'une notification d'avancement. Les verrous qui n'ont pas été récupérés dans le périmètre déclaré ne pourront plus l'être au titre de ces anciennes revendications, ni dans cet épisode, ni dans une instance ultérieure du serveur, ni après le transfert pertinent vers un autre serveur. Terminer signifie aussi renoncer à ce qui reste à réclamer.

Le serveur obtient ainsi une information exploitable : ce client ne reviendra plus compléter cet ancien ensemble. Il peut retirer cette incertitude de ses calculs. En revanche, il ne peut pas prêter la même renonciation aux clients qui n'ont encore rien déclaré.

Le protocole prévoit également une forme limitée à un système de fichiers pour la migration. Elle exige un descripteur de fichier courant et ne remplace pas la déclaration globale associée au nouvel identifiant client. Sur un système de fichiers qui n'est pas dans la situation de migration correspondante, un résultat positif peut être renvoyé sans autre effet. La présente analyse porte sur le redémarrage ; cette distinction sert seulement à éviter de confondre les périmètres.

Comment tenir compte de ceux qui ne répondent pas

Pour savoir que tous les clients concernés ont terminé, le serveur doit savoir lesquels peuvent encore avoir des verrous à récupérer. Une liste conservée en stockage stable permet de donner un sens à l'ensemble des déclarations reçues. Compter uniquement les clients déjà revenus ne suffit pas à établir que personne ne manque.

Une telle connaissance peut permettre une fin anticipée de la grâce. Le serveur peut aussi atteindre la fin de celle-ci sans avoir reçu toutes les déclarations. Mais ce choix reste encadré par les règles liées à la durée du bail. La section 8.4.2.1 indique que la grâce ne devrait pas se terminer avant cette durée ; lorsqu'elle traite d'une modification de la valeur du bail, elle impose un intervalle au moins égal à celui de l'instance précédente.

Ces formulations ne doivent pas être remplacées par une durée universelle inventée. Elles disent surtout qu'une politique de reprise doit respecter l'occasion de récupération promise dans le contexte précédent. Un nouveau démarrage ne permet pas de réécrire arbitrairement le délai auquel les clients devaient se fier.

Le client rapide peut donc avoir entièrement rempli son obligation tout en attendant encore une nouvelle admission. Ce n'est pas nécessairement un échec local. C'est parfois le signe que le serveur n'a pas fini de traiter une obligation collective.

Le danger d'une histoire trop courte

L'attente des absents n'est qu'une partie du problème. Il faut aussi distinguer un droit ancien encore récupérable d'un droit dont la continuité a réellement cessé.

Le RFC décrit une partition empêchant un client de renouveler son bail. Le bail expire et le serveur libère son verrou. Un deuxième client acquiert un verrou qui aurait été incompatible avec le premier, travaille, puis le libère. Le serveur redémarre ensuite. Lorsque la partition disparaît, le premier client revient pendant la nouvelle période de grâce et tente de récupérer son ancien verrou.

Au moment de cette demande, aucun conflit actuel n'est nécessairement visible. Pourtant, accepter la récupération peut être incorrect : le second client a pu modifier l'objet pendant que le premier n'était plus protégé. Le problème n'est pas la présence simultanée de deux lignes contradictoires dans une table. C'est l'acceptation d'une continuité fictive.

Un autre scénario traverse deux redémarrages. Le premier client manque une partie de la première période de récupération ; un autre obtient ensuite un verrou incompatible ; un deuxième redémarrage survient ; le premier client revient enfin. La nouvelle grâce ne doit pas effacer le sens de l'occasion manquée auparavant.

D'où l'alternative imposée au serveur : refuser toutes les récupérations avec NFS4ERR_NO_GRACE, ou conserver suffisamment d'état stable pour détecter les situations dangereuses connues liées au redémarrage. Le texte autorise un refus prudent lorsque des informations plus complètes auraient permis l'acceptation. Si les enregistrements sont irrémédiablement endommagés, les revendications potentiellement touchées doivent être refusées.

Le RFC illustre une forme minimale de suivi par client : identité, révocation non acquittée, récupération précédente potentiellement incomplète. Il ne prescrit pas une structure de base de données unique. La quantité et la précision de l'historique déterminent plutôt jusqu'où le serveur peut être accommodant sans inventer ce qu'il ne sait plus.

L'application conserve sa propre décision

Après un refus de récupération, reprendre un verrou par une demande ordinaire ne démontre pas que l'ancien travail est resté protégé sans interruption. Une attribution présente ne répare pas le passé.

Le RFC laisse le traitement de NFS4ERR_NO_GRACE dépendre de l'environnement du client. Il évoque notamment l'examen de l'attribut de changement de l'objet avant une éventuelle réouverture ou une nouvelle demande de verrou, sous réserve des règles de cet environnement. Ce n'est pas une recette universelle permettant à toute application de continuer sans examen.

La fiche officielle du document présente le RFC 8881 comme une proposition de norme d'août 2020 remplaçant le RFC 5661. La liste des errata consultée distingue corrections vérifiées et propositions signalées. Aucune entrée directement modificatrice des trois sections centrales utilisées ici n'y apparaît. Cela ne certifie ni l'absence de défauts dans l'ensemble du texte ni la conformité des produits actuels.

La Note 32 de Lu Heng sur le problème d'agence invite à relier le pouvoir de décider à l'exposition aux conséquences. Sa Note 36 consacrée à la réalité plutôt qu'au plaidoyer demande de décrire les mécanismes sans leur substituer un affrontement moral. Ces textes donnent ici une perspective éditoriale, non une preuve technique ni un diagnostic des intentions d'un fournisseur.