OpenZFS 2.4.4 ajoute une récupération pour un cas précis de miroir multihôte et documente la compatibilité Linux jusqu’à 7.2. L’opération ne se limite pas à effacer un marqueur périmé : elle modifie l’état des membres inaccessibles après un import contrôlé.
Le cas du miroir bloqué
Les notes de 2.4.4 renvoient au correctif de récupération. Le cas initial comporte des membres de miroir attachés à différents hôtes. Si un hôte tombe avec ses disques, la configuration survivante peut continuer à exiger des écritures sur ces membres désormais inaccessibles. La revendication multihôte n’obtient plus toutes les écritures réussies requises.
Cela diffère de la simple présence d’un ancien signal d’activité. Ce n’est pas non plus une réparation générale des données manquantes ou de toutes les pannes RAIDZ. Il faut comprendre le refus d’import avant de choisir une opération.
Ce que change la commande
Le manuel du tag 2.4.4 décrit zhack mmp reclaim comme un import ponctuel assouplissant le nombre d’écritures requises pour les membres de miroir impossibles à ouvrir. Il marque ces disques hors ligne puis exporte à nouveau le pool. L’import ordinaire suivant se fait en état dégradé, avec ces membres toujours hors ligne.
Les écritures, l’attente et la relecture du contrôle d’activité restent effectuées. L’opération ne désactive pas simplement toute protection multihôte. Un importateur concurrent partageant du stockage visible peut toujours être détecté.
En revanche, un pair actif dont tous les disques sont invisibles localement ne peut être détecté par ces accès. Il faut neutraliser le pair défaillant par fencing, ou prouver qu’il est éteint, avant la récupération. Un ping ou une connexion SSH en échec ne démontre pas l’arrêt de ses écritures.
Une illustration originale à deux hôtes
Imaginons un miroir avec A visible localement et B attaché au pair défaillant. La configuration attend encore les deux. La revendication ordinaire exige deux écritures, mais seul le membre local est accessible. Après neutralisation du pair, la récupération peut marquer B hors ligne et laisser le pool exporté. L’import suivant utilise cette configuration dégradée.
Le schéma représente cette transition précise, pas un journal de commande ni une récupération réellement effectuée par PeopleAreGeek. Le manuel documente aussi une limite : un disque détenant l’unique copie de certaines données ne peut être mis hors ligne ainsi. L’outil peut signaler un échec au lieu de produire une récupération exploitable.
La compatibilité de mise à jour est un autre choix
La version documente Linux 4.18-7.2 et des corrections, dont une boucle infinie d’écriture et des lectures mmap après la fin du fichier. Installer un paquet compatible ne démontre pas qu’un pool nécessite reclaim, ni qu’il faut activer de nouveaux indicateurs de fonctionnalités du pool.
Gardez les paquets du module noyau et des outils utilisateur cohérents, conservez un chemin de démarrage fonctionnel et suivez la documentation versionnée adaptée à la topologie. Cet article précise le cas d’emploi ; ce n’est pas un raccourci d’import à automatiser.
Revue du 8 septembre : faits et évolutions vérifiés, explications et médias repris.