Résumé

  • RFC 9561 associe le layout SCSI de pNFS aux espaces de noms, réservations, opérations de fencing et flush NVMe.
  • Un NGUID désigne une cible, une commande Preempt demande un changement d’état et un Flush achevé étaye une affirmation limitée de persistance ; aucun ne prouve seul le résultat du fichier.
  • La chaîne exploitable relie l’identité d’hôte, tous les contrôleurs, l’état de réservation, le rejet après fencing, le cache volatile, LAYOUTCOMMIT et la lecture ultérieure.

Le serveur de métadonnées vient de répondre à LAYOUTCOMMIT. L’interface affiche du vert. Pourtant, elle ne dit pas encore si l’ancien client a perdu tous ses chemins, si les octets ont quitté le cache volatile ni si l’application relira le bon état. RFC 9561 fournit les opérations communes ; il maintient ces preuves séparées.

Publié en avril 2024 sur le Standards Track de l’IETF, RFC 9561 n’invente pas un nouveau layout. Il transpose vers NVMe les concepts SCSI de RFC 8154, indépendamment du transport du contrôleur : PCIe, RDMA, TCP ou Fibre Channel.

Un nom précis n’est pas une observation

L’espace de noms doit fournir EUI64 ou NGUID. Le designator binaire du volume pNFS porte l’un des deux ; sa longueur XDR — huit ou seize octets — permet de les distinguer. Cette convention empêche deux implémentations de parler de formats différents.

Elle ne démontre ni le contenu actuel du volume ni l’accord de tous les chemins. Les clés de réservation NVMe couvrent tous les contrôleurs associés au même Host Identifier. Une incohérence de cet identifiant peut donc changer la portée réelle d’une réservation sans modifier le nom logique du fichier.

L’éviction doit se voir au niveau du stockage

Avant de rendre le volume, le MDS enregistre sa clé et acquiert une réservation Exclusive Access – Registrants Only. Pour évincer un client muet, il émet Preempt ou Preempt and Abort en indiquant sa clé et celle du client visé. Celui-ci peut reconnaître l’éviction par le statut Reservation Conflict.

Le reçu de commande ne suffit pas. RFC 8154 formule le résultat attendu : toutes les E/S du client évincé doivent être rejetées. Il faut donc conserver l’état avant/après, l’inventaire des contrôleurs et un test sur chaque chemin. Sans ce raccord, une préemption réussie peut coexister avec un accès ancien non observé.

Après une erreur NVMe non réessayable marquée DNR, le client doit committer les layouts concernés via le MDS, rendre les layouts restants, oublier l’identifiant du dispositif et désenregistrer sa clé. La norme attribue la responsabilité ; elle ne certifie pas l’exécution d’un client concret.

Le commit cache une condition sur le cache

Si VWC et WCE indiquent un cache d’écriture volatile actif, le MDS doit lancer NVMe Flush avant de répondre à LAYOUTCOMMIT. Le mapping assimile ce flush à SCSI SYNCHRONIZE CACHE. Une réponse réussie porte donc une affirmation de persistance, mais seulement pour le namespace, l’ordre et le statut de commande réellement observés.

Cette persistance n’est ni la réplication, ni la lecture future, ni la transaction métier. De même, la sécurité NFS/RPC du chemin vers le MDS ne protège pas automatiquement les E/S NVMe. NVMe/TCP peut employer TLS, tandis que PCIe peut n’ajouter presque aucun mécanisme. Enfin, NFS raisonne en utilisateurs et fichiers ; NVMe, en initiateurs et volumes. Le client doit préserver la correspondance.

La méthode de Lu Heng consiste à ne pas confondre ces couches : identifiant, intention, commande exécutée, état du dispositif et effet vu par l’application.