8.10. Systèmes de fichiers et stockage

Les entrées de journal n'interrompent plus l'écriture du journal

Auparavant, dans le pilote VDO, pendant l'opération de suspension du device-mapper et après la reprise du fonctionnement du device, certains blocs de journal pouvaient encore être marqués comme étant en attente de certaines mises à jour de métadonnées avant de pouvoir être réutilisés, même si ces mises à jour avaient déjà été effectuées. Lorsqu'il y avait suffisamment d'entrées dans le journal pour que le journal puisse revenir au même bloc physique, celui-ci n'était pas disponible. Les écritures dans le journal s'arrêtaient, attendant que le bloc devienne disponible, ce qui ne se produisait jamais. Par conséquent, lorsque certaines opérations sur un périphérique VDO comprenaient un cycle de suspension ou de reprise, le périphérique se trouvait dans un état figé après certaines mises à jour du journal. Les mises à jour du journal avant cet état étaient imprévisibles car elles dépendaient des schémas d'allocation précédents au sein de la VDO, et des schémas d'écriture ou d'abandon entrants. Avec cette mise à jour, après le cycle de suspension ou de reprise de l'enregistrement des données, l'état de la structure de données interne est réinitialisé et les blocages ne se produisent plus.

L'ajout d'un périphérique de données ne déclenche plus d'échec d'assertion

Auparavant, lors de l'ajout de périphériques supplémentaires au cache, Stratis n'utilisait pas le cache immédiatement après l'initialisation. Par conséquent, le service stratisd renvoyait un message d'échec d'assertion chaque fois qu'un utilisateur tentait d'ajouter des périphériques de données supplémentaires à un pool. Avec cette correction, le cache est maintenant utilisé immédiatement après l'initialisation et aucun échec d'assertion ne se produit.

Résolution d'erreurs lors de l'ajout de nouveaux périphériques de données au pool crypté

Auparavant, lorsque l'utilisateur initialisait un pool chiffré avec des périphériques de données chiffrés, à l'aide d'une commande Clevis bind sur un serveur tang, spécifié avec l'option --trust-url, stratisd n'incluait pas la partie thumbprint de la configuration Clevis tang dans les structures de données internes. Par conséquent, un échec se produisait lors de la tentative d'ajout de nouveaux périphériques de données au pool. Avec cette mise à jour, les structures de données internes de stratisd incluent désormais la partie thumbprint de la configuration Clevis tang.

La connexion à des espaces de noms NVMe à partir d'initiateurs Broadcom sur des systèmes AMD EPYC ne nécessite plus de paramètres IOMMU autres que ceux par défaut

Par défaut, le noyau RHEL active l'IOMMU sur les plateformes basées sur AMD. Auparavant, le pilote lpfc n'utilisait pas les macros d'accesseur de la liste de dispersion. Par conséquent, certains serveurs équipés de processeurs AMD rencontraient des problèmes d'E/S NVMe, tels que des E/S échouant en raison de la non-concordance des longueurs de transfert.