Version courte :

Vous devez procéder dans l'autre sens : remplacer le disque de pool défaillant (par un nouveau disque ou par lui-même) et ensuite, détacher le disque de rechange du pool (afin qu'il devienne disponible pour tous les vdev). Je suppose que le disque de rechange est occupé tant que le disque qu'il a servi à remplacer n'est pas lui-même remplacé. Détacher ce disque ou un autre disque ne fait qu'empirer la situation.

Aussi, je me souviens que ZoL n'a pas d'attachement/détachement automatique pour les pièces de rechange en fonction des événements, vous devez script votre propre ou utiliser quelque chose comme le Démon d'événements ZFS .

Version longue :

En ce qui concerne votre commentaire de suivi

Si le disque C est défectueux, ok, remplaçons-le puis détachons-le. Mais cela a perturbé mon pool, parce que zpool ne s'est pas souvenu que j'avais un disque C dans le miroir-1 :/

Cela dépend de la façon dont vous le voyez. Si vous détachez un disque d'un miroir, il n'est plus pertinent. Il peut être défectueux, il peut être utilisé sur un autre système, il peut être remplacé sous la garantie du fabricant. Quoi qu'il en soit, votre piscine s'en moque.

Si vous vous contentez de détacher le disque, il sera dégradé ; si, au contraire, vous fournissez un autre disque (à partir d'un remplacement automatique, d'un remplacement manuel ou d'un remplacement entièrement manuel), ce disque assumera le rôle de l'ancien disque (d'où l'expression replace le nouveau disque remplace entièrement l'ancien disque dans sa position et ses fonctions).

Si vous le souhaitez, vous pouvez réintégrer le disque détaché dans le pool, par exemple en tant que disque de rechange (la situation initiale est donc inversée).

Comment les pièces de rechange fonctionnent sur les systèmes ZFS

Les pièces de rechange n'ont vraiment de sens qu'en cas d'activation automatique. Les matrices de stockage ZFS telles que conçues par Sun comportaient de nombreux disques similaires, des quantités de 18 à 48 disques n'étant pas rares. Elles étaient composées de plusieurs vdev, par exemple 4 x RAID Z2 pour un système de 24 disques. De plus, ils étaient gérés par un administrateur dédié, mais personne ne peut travailler 24 heures sur 24, 7 jours sur 7. Ils avaient donc besoin d'une solution de première intervention, qui devait fonctionner sur tous les disques virtuels, car n'importe quel disque pouvait tomber en panne à tout moment.

Ainsi, si tard dans la nuit un disque de votre deuxième vdev tombe en panne, le système prend automatiquement l'un des deux disques de rechange configurés et remplace le disque défectueux de sorte que le pool fonctionne comme d'habitude (même performance pour les clients qui utilisent un site web dont la base de données tourne dessus, par exemple). Le matin, l'administrateur lit le rapport de la panne et en recherche la cause :

• Si le disque est mort, il peut le remplacer par un disque de rechange dans le même plateau, le laisser se réarmer, puis le disque de secours est automatiquement remis en service, à la recherche d'un autre disque mort où il pourra effectuer la première réponse.
• Si aucun disque de remplacement n'est disponible, il peut même faire du disque de rechange le nouveau disque de données, réduisant temporairement le nombre de disques de rechange de 1 (jusqu'à ce qu'un autre disque de remplacement soit expédié et devienne le nouveau disque de rechange).
• S'il s'agissait simplement d'une erreur de contrôleur faisant tomber le disque, il pourrait même le remplacer par lui-même, déclenchant le même renouvellement de la réserve que dans le premier cas.

Si vous y réfléchissez comme les ingénieurs l'ont conçu pour le scénario d'utilisation le plus courant, cela aura beaucoup plus de sens. Cela ne signifie pas que vous devez faire exactement ce qui est décrit, mais que ce comportement peut s'expliquer.

Réponses à vos questions

Pourquoi le remplacement du disque C n'est pas suffisant pour reconstruire un pool complet ? Comme expliqué sur le blog d'oracle et ici aussi, je m'attendais à ce que je ne doive pas détacher le disque pour que zfs reconstruise le pool correctement (et c'est bien mieux de garder dans le statut de zpool les traces du disque débranché, pour la commodité de la maintenance).

Comme vu ci-dessus, vous pouvez soit remplacer le disque de pool par un autre ou par lui-même (le spare sera libre et continuera à fonctionner comme spare), soit détacher le disque de pool, alors que le spare assumera définitivement le rôle de disque de pool et vous devrez ajouter un autre spare à la main avec zpool add poolname spare diskname (qui peut être le disque détaché ou un nouveau).

Pourquoi zpool continue à me dire que les disques de secours sont "occupés" (ils ne le sont vraiment pas) ?

Je suppose que c'était à cause de l'IO exceptionnelle. Cela expliquerait pourquoi l'opération a pris un moment pour se terminer.

Voir ci-dessous : comment puis-je récupérer automatiquement mon disque de rechange ?

• Activez le remplacement automatique des pièces de rechange (par défaut sur Solaris/illumos, un peu compliqué sur Linux).
• Remplacez le disque de pool défectueux par zpool replace (au lieu de le détacher). L'étape de détachement n'est nécessaire que pour le disque de rechange après le remplacement du disque du pool et si vous n'avez pas de gestion automatique (ce qui n'a aucun sens à mes yeux, sauf pour des dispositions de pool spécifiques et des situations d'administration).