OpenZFS 2.4.4 est sorti le vendredi vingt et un août 2026, et le changement le plus susceptible d'épargner une mauvaise soirée à quelqu'un est une nouvelle commande zhack mmp reclaim. Elle récupère un pool bloqué par la protection multi-modificateurs, le mécanisme qui empêche deux hôtes d'importer le même pool et de le détruire. La version ajoute aussi la prise en charge de Linux 7.2, portant la plage de noyaux pris en charge de 4.18 à 7.2, et rend systemd-udev-settle facultatif pour les unités d'import. Plusieurs vrais bogues se referment en dessous : une boucle infinie dans zfs_write, des lectures mmap au-delà de la fin de fichier, et fallocate qui n'actualisait pas les horodatages.
The short answer
OpenZFS 2.4.4 est sorti le vendredi vingt et un août 2026. Une nouvelle commande zhack mmp reclaim récupère les pools bloqués par la protection multi-modificateurs. La prise en charge de Linux 7.2 arrive via une conversion vers l'interface sget_fc() du noyau, portant la plage de 4.18 à 7.2, et systemd-udev-settle devient facultatif pour les unités d'import. Les correctifs couvrent une boucle infinie dans zfs_write, les lectures mmap au-delà de la fin de fichier et les horodatages de fallocate. OpenZFS 2.3.9 et 2.2.11 sont sortis en parallèle.
Les versions mineures d'un système de fichiers se résument d'habitude à une mise à niveau de compatibilité noyau et à une liste de correctifs que personne ne lit. Celle-ci apporte une commande de récupération, et les commandes de récupération méritent d'être connues avant d'en avoir besoin plutôt que pendant.
La défaillance que MMP est conçu pour provoquer
La protection multi-modificateurs existe pour empêcher la pire chose qui puisse arriver à un pool partagé : deux hôtes qui l'importent simultanément et écrivent l'un par-dessus l'autre. L'hôte qui importe inscrit une pulsation dans les uberblocks du pool. Tout autre hôte qui tente un import voit une pulsation vivante et refuse.
Le mécanisme fonctionne. Le problème est ce qui se passe quand la pulsation survit à son auteur. Un nœud panique en pleine écriture. Un chemin de stockage tombe exactement au mauvais moment. Le pool reste porteur d'un état MMP affirmant que quelqu'un le détient, et ce quelqu'un n'existe plus.
À partir de là, chaque tentative d'import est refusée. Le refus est correct au regard des règles et totalement inutile pour la personne d'astreinte, et jusqu'ici les issues étaient un import forcé avec le risque associé, ou une chirurgie bas niveau improvisée.
Ce que la nouvelle commande apporte
OpenZFS 2.4.4 ajoute zhack mmp reclaim, qui efface l'état MMP obsolète pour que le pool puisse être importé normalement.
zhack est l'outil de manipulation bas niveau des pools, et y placer la récupération est le bon choix. Cela signale ce qu'est réellement l'opération : une affirmation explicite d'un exploitant selon laquelle le détenteur précédent a définitivement disparu. Ce n'est pas quelque chose qu'un script de démarrage devrait invoquer.
L'essentiel est l'ordre, et il n'est pas négociable. Confirmez que l'autre hôte est hors service. Pas injoignable depuis votre terminal, pas silencieux à un ping, mais isolé et confirmé. MMP est ce qui vous sépare d'un double import, et effacer cet état manuellement retire cette protection pour l'import qui suit.
Dans une configuration en grappe, cela veut dire passer par le gestionnaire de grappe plutôt que le contourner, aussi tentant que paraisse le raccourci au moment où vous exécutez déjà de la chirurgie bas niveau. La commande rend la récupération possible. Elle ne rend pas la vérification facultative.
Prise en charge du noyau et temps de démarrage
La prise en charge de Linux 7.2 arrive ici, portant la plage officiellement prise en charge de 4.18 à 7.2. Le travail de compatibilité principal a consisté à convertir le code de superbloc ZFS vers l'interface sget_fc() du noyau, dans la continuité de la longue conversion du contexte de système de fichiers en amont. La prise en charge de FreeBSD se poursuit pour 13.3 et ultérieures et 14.0 et ultérieures.
Le changement que davantage de gens remarqueront est que systemd-udev-settle devient facultatif pour les unités d'import. Cette dépendance imposait une attente inconditionnelle que udev finisse de traiter chaque périphérique avant que les pools ne s'importent. Sur un système à quelques disques, c'est invisible. Sur un système équipé d'une grande baie, c'est une part mesurable du temps de démarrage passée à attendre un traitement de périphériques sans rapport avec le pool que vous importez.
Les correctifs qui mordent en silence
Trois correctifs Linux ressortent, moins par leur énoncé que par la façon dont ils se manifestent.
Une boucle infinie dans zfs_write() sur un tampon non faultable est corrigée. Ce défaut se présente comme un processus coincé indéfiniment sans erreur exploitable nulle part, ce qui compte parmi les choses les moins agréables à diagnostiquer sur un serveur de stockage.
Les lectures via mmap() au-delà de la fin d'un fichier se comportent désormais correctement, et fallocate() actualise les horodatages de modification et de changement quand il agrandit un fichier. Le correctif d'horodatage semble cosmétique et ne l'est pas. Les outils de sauvegarde, les systèmes de compilation et les agents de synchronisation décident de travailler ou non en comparant des horodatages, et un fichier qui grandit sans que sa date de modification bouge est un fichier qui n'est plus sauvegardé, en silence.
S'y ajoutent des correctifs de table de déduplication couvrant des dépassements de temps négatifs, des bogues d'élagage et des problèmes de compteurs de références, ainsi qu'une nouvelle permission déléguée send:encrypted offrant un contrôle plus fin sur les opérations concernant les jeux de données chiffrés.
Conseils de mise à jour
Si vous utilisez OpenZFS sur un noyau 7.2, ou si c'est prévu prochainement, c'est la version qui vous prend en charge. Si vous êtes sur une branche plus ancienne, OpenZFS 2.3.9 et 2.2.11 sont sortis le même jour avec des correctifs rétroportés, il existe donc une voie qui n'impose pas de changer de branche.
Pour tout le monde, la réponse honnête est que c'est une version mineure ordinaire et que les règles habituelles s'appliquent. Mettez à jour selon votre calendrier. La seule chose qui vaut la peine d'être faite aujourd'hui, que vous mettiez à jour ou non, est de lire la procédure de récupération MMP pendant que rien n'est cassé, car le moment où vous aurez réellement besoin de zhack mmp reclaim est le pire moment possible pour découvrir ce qu'elle fait.
Sources et pour aller plus loin
- OpenZFS 2.4.4 sort avec la prise en charge de Linux 7.2 et des dizaines de correctifs, Phoronix, 21 août 2026
- OpenZFS 2.4.4 ajoute la prise en charge du noyau Linux 7.2 et un nouvel outil de récupération MMP, Linuxiac, août 2026
- Notes de version OpenZFS 2.4.4, GitHub
Questions fréquentes
Qu'est-ce que MMP et comment un pool se retrouve-t-il bloqué ?
La protection multi-modificateurs est la sauvegarde de ZFS contre l'import simultané d'un même pool par deux hôtes, ce qui le corromprait. L'hôte qui importe inscrit une pulsation dans les uberblocks du pool, et tout autre hôte qui tente un import voit cette pulsation et refuse. Le mode de défaillance survient quand la pulsation survit à l'hôte qui l'a écrite. Un nœud meurt en pleine écriture, ou un chemin de stockage partagé casse au mauvais moment, et le pool porte un état MMP affirmant que quelqu'un le détient alors que personne ne le détient. Tout import ultérieur est refusé, correctement selon les règles et inutilement de votre point de vue.
Que fait zhack mmp reclaim exactement ?
Elle efface l'état MMP obsolète pour que le pool puisse être importé de nouveau. zhack est l'outil de chirurgie bas niveau d'OpenZFS, et la sous-commande reclaim est une façon délibérée et explicite d'affirmer que le détenteur précédent a bel et bien disparu. Avant cette version, les issues consistaient en un import forcé avec les risques associés, ou une intervention manuelle avec des outils qui n'avaient jamais été conçus pour cela. Disposer d'une commande nommée signifie que le chemin de récupération est documenté et relu, plutôt qu'improvisé à partir d'un fil de liste de diffusion à trois heures du matin.
Quand ne faut-il surtout pas l'exécuter ?
Quand vous n'avez pas vérifié qu'aucun autre hôte n'a le pool importé. Toute la raison d'être de MMP est d'empêcher un double import, et effacer l'état manuellement retire cette protection pour l'import qui suit. Si l'autre nœud est simplement injoignable depuis l'endroit où vous vous trouvez plutôt que confirmé hors service, vous n'avez pas l'information nécessaire. Isolez l'autre nœud, confirmez qu'il l'est, puis exécutez la récupération. Dans une configuration en grappe, cela signifie passer par le gestionnaire de grappe et non le contourner. La commande rend la récupération possible, elle ne rend pas la vérification superflue.
Qu'est-ce qui change pour la prise en charge du noyau Linux ?
OpenZFS 2.4.4 ajoute la prise en charge du noyau stable Linux 7.2, portant la plage officiellement prise en charge de 4.18 à 7.2. Le principal travail de compatibilité a consisté à convertir le code de superbloc ZFS vers l'interface sget_fc() du noyau, dans la continuité de la conversion du contexte de système de fichiers en amont. La prise en charge de FreeBSD se poursuit pour les versions 13.3 et ultérieures et 14.0 et ultérieures. La version rend aussi la dépendance systemd-udev-settle facultative pour les unités d'import, ce qui supprime une attente inconditionnelle de la fin du traitement des périphériques avant l'import des pools, attente qui peut peser lourdement au démarrage sur des systèmes à nombreux disques.
Quelles corrections comptent le plus au quotidien ?
Trois ressortent sous Linux. Une boucle infinie dans zfs_write() pouvant se déclencher sur un tampon non faultable est corrigée, un défaut qui se présente comme un processus figé que personne ne sait expliquer. Les lectures via mmap() au-delà de la fin d'un fichier se comportent désormais correctement. Et fallocate() actualise maintenant les horodatages de modification et de changement quand il agrandit un fichier, ce qui paraît cosmétique jusqu'à ce qu'un outil de sauvegarde ou un système de compilation décide que rien n'a changé parce que l'horodatage le dit. S'y ajoutent des correctifs de la table de déduplication couvrant des dépassements de temps négatifs, des bogues d'élagage et des problèmes de compteurs de références, plus une nouvelle permission déléguée send:encrypted.