Remplacement de disques ZFS : procédure sûre pour éviter les drames du pool

Ce que signifie « sûr » dans le remplacement de disques ZFS

Dans ZFS, « sûr » n’est pas une impression. C’est une séquence de vérifications qui prévient trois défaillances classiques :

• Remplacer le mauvais disque (l’erreur opérateur n°1). C’est comme transformer la redondance en pile ou face.
• Utiliser le mauvais chemin de périphérique (bonjour, roulette /dev/sdX), ce qui fait que le pool « répare » sur un autre disque physique que vous pensiez.
• Déclarer la victoire trop tôt : le resilver se termine, mais vous n’avez pas corrigé le problème de transport/contrôleur sous-jacent, donc le disque suivant « lâche » par sympathie.

Voici la vérité opérationnelle : ZFS excelle pour l’intégrité des données et dit honnêtement ce qu’il sait. Mais ZFS ne peut pas vous protéger des numéros de baie confus, des expanders SAS défectueux, des backplanes mal câblés, ni d’un disque de remplacement DOA. Votre workflow doit combler cet écart.

Utilisez le bon verbe ZFS ou subissez les conséquences

Le « remplacement » de disque dans ZFS peut signifier plusieurs choses :

• zpool replace : remplacer un device leaf spécifique par un autre. C’est la voie habituelle pour les disques défaillants.
• zpool attach : ajouter un disque à un vdev mono-disque existant pour créer un mirror, ou ajouter un disque à un mirror existant (rare ; prudence). Ce n’est pas un remplacement.
• zpool detach : retirer un disque d’un vdev mirror (jamais d’un RAIDZ). Utilisé après des migrations basées sur attach ou pour réduire un mirror.
• zpool offline/online : mettre un disque hors service temporairement. Utile quand vous voulez contrôler le timing.

Un autre : zpool clear n’est pas une réparation. Il réinitialise les compteurs d’erreurs. Cela peut être approprié après avoir corrigé un problème de câblage et vouloir confirmer la stabilité. Ce n’est pas un rituel pour faire disparaître les alertes.

Idée paraphrasée de Gene Kim : le vrai travail de la fiabilité est de faire du chemin normal le chemin sûr. Cela s’applique aux échanges de disques autant qu’aux déploiements.

Petite blague #1 : Si votre plan repose sur « Je me souviendrai quel disque c’est », félicitations — vous venez d’inventer le stockage non persistant pour les humains.

Faits intéressants et brève histoire (pour cesser de lutter contre le système)

• ZFS a été conçu pour détecter la corruption silencieuse des données. Les checksums sont stockés séparément des données, donc un disque ne peut pas « corriger son propre devoir ».
• Le resilver a évolué : OpenZFS moderne supporte le resilver séquentiel, ce qui est généralement plus doux pour les pools fragmentés et plus rapide sur disques rotatifs.
• Les scrub existent bien avant beaucoup d’idées « cloud-native ». Un scrub ZFS est essentiellement une vérification continue à large échelle, bien avant que « integrity scanning » ne devienne à la mode.
• RAIDZ n’est pas RAID5. Objectifs similaires, implémentation très différente : ZFS a le checksum de bout en bout et un modèle transactionnel qui évite le write hole classique.
• ashift est pour toujours. Une fois qu’un vdev est créé avec un ashift (exposant de taille de secteur), vous ne le changez pas sans reconstruire le vdev.
• Les guerres de noms de périphériques sont anciennes. Les administrateurs se sont fait avoir par des noms instables depuis l’époque pré-SATA ; les identifiants persistants existent parce que les humains continuent de perdre ce combat.
• Le « autoexpand » de ZFS existe parce que les upgrades sont normaux. Mais ce n’est pas magique. Il a des règles et un timing, et il ne réparera pas des vdevs de tailles mismatched.
• ZFS peut utiliser un separate intent log (SLOG) pour accélérer les écritures synchrones, mais cela n’aide pas la vitesse de resilver et peut compliquer la gestion des pannes.
• SMART n’est pas une vérité, c’est un témoignage. Des disques meurent sans prévenir ; d’autres crient pendant des mois et continuent de fonctionner. ZFS utilise checksums et redondance pour rester dans la réalité.

Pré-vol : quoi vérifier avant de toucher le matériel

Le remplacement de disque est une chorégraphie entre ZFS, l’OS, le contrôleur/HBA, le chassis/backplane, et la personne qui tient la caddy. L’objectif est de réduire l’incertitude avant d’ôter quoi que ce soit.

Règles que je suis en production

• Pas de retrait de disque sans confirmation du numéro de série. Les numéros de baie mentent. Les étiquettes dérivent. Les humains lisent mal. Les numéros de série s’en fichent.
• Effectuer un scrub ou au moins évaluer l’état du scrub en premier. Si le pool a déjà des erreurs de checksum, le resilver n’est pas une parade de victoire — c’est un stress test.
• Ne pas lancer un resilver pendant une fenêtre sensible en performance à moins de limiter volontairement et d’accepter le rayon d’impact.
• Préférer les identifiants persistants de périphérique (chemins by-id) pour les opérations de replace et pour la configuration du vdev à long terme.
• Valider le disque de remplacement : taille des secteurs, capacité, type de transport, et « est-ce vraiment le bon disque ».

Tâches pratiques : commandes, ce que signifient les sorties, et la décision à prendre

Les tâches suivantes sont volontairement répétitives. C’est le but. Les échanges de disques échouent quand les gens improvisent.

Tâche 1 : Confirmer l’état du pool et identifier le vdev problématique

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Tue Dec 24 01:12:18 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A125            UNAVAIL      0     0     0  cannot open
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Signification : ZFS ne peut pas ouvrir un leaf device ; la redondance maintient le pool en ligne. L’historique du scrub est propre. Bon signe.

Décision : Remplacer ...VKJ0A125. Ne touchez pas aux autres disques. Si plusieurs sont instables, marquez une pause et inspectez le câblage/backplane avant de remplacer davantage de matériel.

Tâche 2 : Obtenir l’arbre complet du vdev avec les noms persistants (et voir si vous les utilisez déjà)

cr0x@server:~$ sudo zpool status -P tank
  pool: tank
 state: DEGRADED
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A123  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A124  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A125  UNAVAIL      0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A126  ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A127  ONLINE       0     0     0

Signification : La configuration du pool utilise des chemins by-id stables. C’est ce que vous voulez.

Décision : Continuer à utiliser /dev/disk/by-id/... pour le remplacement. Si vous voyez /dev/sdX, corrigez cela pendant/après le remplacement (détails plus loin).

Tâche 3 : Confirmer que l’OS voit bien le disque défaillant (ou qu’il a vraiment disparu)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A125 || true

Signification : Si le chemin est absent, le disque n’est pas énuméré — il peut être mort, le slot peut être mort, ou le lien peut être coupé.

Décision : S’il est manquant, vérifiez les logs du contrôleur et le lien physique avant de supposer que le disque est l’unique problème.

Tâche 4 : Extraire les erreurs récentes du noyau/stockage (repérer des problèmes de contrôleur/backplane)

cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|link|I/O error|blk_update_request" | tail -n 25
[Wed Dec 24 09:42:11 2025] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Wed Dec 24 09:42:11 2025] ata9.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 09:42:11 2025] blk_update_request: I/O error, dev sdi, sector 123456789
[Wed Dec 24 09:42:12 2025] ata9: hard resetting link
[Wed Dec 24 09:42:13 2025] ata9: link is slow to respond, please be patient
[Wed Dec 24 09:42:18 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 24 09:42:19 2025] sd 9:0:0:0: [sdi] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Signification : Resets de lien et erreurs I/O. Cela peut être le disque. Cela peut être le slot/le câble.

Décision : Si plusieurs disques sur le même port montrent des resets, arrêtez et inspectez l’HBA/backplane. Si c’est isolé à un disque, le remplacement est raisonnable.

Tâche 5 : Cartographier le by-id au slot physique (outils d’enceinte)

Sur des enceintes SAS, vous avez souvent sg_ses / sesutil / outils vendor. Sur Linux avec des HBAs courants, commencez par lsblk et udevadm.

cr0x@server:~$ lsblk -o NAME,SIZE,SERIAL,MODEL,HCTL,PATH | egrep "sdi|VKJ0A125|NAME"
NAME   SIZE SERIAL    MODEL          HCTL       PATH
sdi   7.3T  VKJ0A125  WDC WD80EFAX   9:0:0:0    /dev/pci0000:3b/0000:3b:00.0/ata9/host8/target8:0:0/8:0:0:0/block/sdi

Signification : Vous avez le numéro de série et le HCTL/chemin. C’est votre fil d’Ariane vers la bonne baie.

Décision : Utilisez cette cartographie avec la documentation de votre chassis ou la gestion de l’enceinte pour identifier la baie exacte avant d’ôter quoi que ce soit.

Tâche 6 : Confirmer que le disque de remplacement est sain (taille, secteur, transport)

cr0x@server:~$ sudo smartctl -a /dev/sdj | egrep "Model|Serial|User Capacity|Sector Size|Rotation Rate|SMART overall|SATA Version"
Device Model:     WDC WD80EFAX-68LHPN0
Serial Number:    VKJ0B555
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Size:      512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
SMART overall-health self-assessment test result: PASSED
SATA Version is:  SATA 3.3, 6.0 Gb/s

Signification : La capacité correspond, secteurs physiques 4Kn, SMART passe. Bon indicateur de base.

Décision : Si le remplacement est plus petit (même légèrement), stoppez. ZFS ne peut pas remplacer un disque par un plus petit dans le même vdev. Si les caractéristiques de secteur diffèrent, poursuivez mais attendez-vous à des conséquences de performance/ashift (couvert plus loin).

Tâche 7 : Vérifier la réalité de l’ashift du pool (parce que les surprises arrivent)

cr0x@server:~$ sudo zdb -C tank | egrep "ashift|vdev_tree|path" | head -n 30
        vdev_tree:
            type: 'raidz'
            id: 0
            ashift: 12
            children[0]:
                path: '/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A123'
            children[1]:
                path: '/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0A124'

Signification : ashift: 12 (4K). C’est typiquement correct pour les disques modernes.

Décision : Si vous voyez ashift: 9 sur des disques 4K, ne « corrigez » pas en remplaçant des disques. Planifiez une reconstruction/migration de vdev quand vous pouvez vous le permettre.

Tâche 8 : Mettre le disque défaillant en offline (retrait contrôlé)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80EFAX-68LHPN0_VKJ0A125

Signification : ZFS cesse d’utiliser ce disque et s’attend à son absence. Cela réduit le chaos quand vous retirez le disque.

Décision : Mettez offline avant le retrait physique sauf si le disque a déjà disparu. Si le pool a déjà perdu le disque, l’offline peut ne pas changer grand-chose.

Tâche 9 : Confirmer que le disque est bien offline (et pas un autre disque)

cr0x@server:~$ sudo zpool status tank | sed -n '1,35p'
  pool: tank
 state: DEGRADED
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A125            OFFLINE      0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

Signification : Le leaf correct est offline. Si vous voyez un autre disque offline, arrêtez immédiatement et annulez votre dernière commande.

Décision : Procédez au remplacement physique.

Tâche 10 : Après insertion du nouveau disque, trouver son chemin by-id stable

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep "VKJ0B555|WDC_WD80EFAX" | tail -n 5
lrwxrwxrwx 1 root root  9 Dec 24 10:11 ata-WDC_WD80EFAX-68LHPN0_VKJ0B555 -> ../../sdj
lrwxrwxrwx 1 root root 10 Dec 24 10:11 ata-WDC_WD80EFAX-68LHPN0_VKJ0B555-part1 -> ../../sdj1

Signification : L’OS voit le nouveau disque comme sdj, mais vous utiliserez le chemin by-id.

Décision : Utilisez /dev/disk/by-id/ata-...VKJ0B555 pour zpool replace.

Tâche 11 : Effacer les anciennes étiquettes sur le disque de remplacement (éviter les fantômes d’import)

cr0x@server:~$ sudo zpool labelclear -f /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Signification : Efface les labels ZFS qui pourraient confondre le remplacement (commun avec des disques réutilisés).

Décision : Si cela échoue car le disque est occupé, arrêtez et vérifiez que vous n’avez pas choisi par erreur un disque déjà en service.

Tâche 12 : Remplacer le disque offline par le nouveau disque

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_VKJ0A125 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Signification : ZFS commence le resilvering vers le nouveau disque. L’identité de l’ancien disque est maintenant associée au nouveau device physique.

Décision : Commencez à surveiller le resilver immédiatement. Si le pool ne démarre pas le resilver, vérifiez le mauvais chemin, le mauvais nom de leaf, ou l’absence réelle du disque.

Tâche 13 : Surveiller la progression du resilver (et apprendre ce qu’est un « bon » comportement)

cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank

  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        1.82T scanned at 920M/s, 612G issued at 308M/s, 1.82T total
        102G resilvered, 32.83% done, 03:44:10 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

Signification : Vous obtenez scanned, issued, le débit courant, l’ETA, et la feuille marquée « (resilvering) ».

Décision : Si le débit s’effondre ou si l’ETA devient sans borne, passez au Playbook de diagnostic rapide. N’attendez pas des heures en espérant que « ça se règle tout seul ».

Tâche 14 : Vérifier la montée des erreurs read/write/checksum pendant le resilver

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,60p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        2.34T scanned, 1.01T issued, 180G resilvered, 54.11% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     2
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     1     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Signification : Les erreurs augmentent sur d’autres disques, pas seulement sur le disque remplacé. C’est l’odeur d’un problème partagé (câble, expander, HBA, alimentation).

Décision : Mettez une pause aux changements opérationnels. Envisagez de limiter les charges, vérifier les erreurs de transport, et éventuellement mettre offline un second disque malade seulement si la redondance le permet et si vous avez un plan.

Tâche 15 : Quand le resilver se termine, vérifier que le pool est vraiment sain

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: resilvered 1.09T in 04:18:51 with 0 errors on Wed Dec 24 14:32:53 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A123            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A124            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0B555            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A126            ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ0A127            ONLINE       0     0     0

errors: No known data errors

Signification : Le pool est ONLINE, le resilver est terminé, et aucune erreur n’a été enregistrée.

Décision : Planifiez un scrub plus tôt que d’habitude si le pool a montré une quelconque instabilité. Un scrub après un resilver est le geste « faire confiance mais vérifier ».

Tâche 16 : Confirmer la politique TRIM/autotrim (SSDs et quelques cas SMR)

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  off       local

Signification : Autotrim est off. Sur des pools SSD, cela peut impacter la performance/la réutilisation d’espace ; sur des pools HDD, c’est généralement sans effet.

Décision : Pour des pools SSD, envisagez de l’activer après vérification du firmware/du comportement du contrôleur. Ne touchez pas ces réglages en cours de resilver à moins d’aimer déboguer votre curiosité.

Pas à pas : remplacer un disque dans un mirror (la version la moins dramatique)

Les mirrors sont indulgents. Ils sont aussi le lieu où les gens deviennent négligents, parce que « ce n’est qu’un mirror ». Les mirrors échouent quand vous remplacez le mauvais côté et découvrez que vous fonctionnez sur une jambe depuis des mois.

Workflow de remplacement pour mirror

1. Identifier la leaf défaillante via zpool status -P. Capturer le chemin by-id et le numéro de série.
2. Confirmer la cartographie physique (LED du slot si disponible ; sinon correspondance serial → baie).
3. Mettre offline la leaf défaillante si elle est encore présente : zpool offline pool oldleaf.
4. Remplacer physiquement le disque. Attendre que l’OS l’énumère.
5. labelclear le nouveau disque s’il a pu être utilisé auparavant.
6. Remplacer : zpool replace pool oldleaf newdisk.
7. Surveiller le resilver. Les mirrors resilver souvent rapidement, mais regardez quand même les erreurs sur le disque « bon ».
8. Clôturer avec un scrub planifié bientôt si ce mirror est important.

Quand utiliser attach pour les mirrors

Vous utilisez zpool attach lorsque vous convertissez un vdev mono-disque en mirror, ou lorsque vous voulez volontairement un mirror trois voies temporairement. Pendant les remplacements, replace est la valeur par défaut parce qu’il préserve la topologie et l’intention du vdev.

Pas à pas : remplacer un disque en RAIDZ (où la patience est une qualité)

Les resilvers RAIDZ sont plus lourds. Ils lisent depuis de nombreux disques et reconstruisent les données sur le nouveau. Cette charge peut faire ressortir des disques marginaux, des câbles limites, et des suppositions fragiles.

Workflow de remplacement pour RAIDZ

1. Confirmer la marge de redondance. RAIDZ1 avec un disque défaillant vit sur le fil. RAIDZ2 vous donne de l’air, pas la permission d’être négligent.
2. Vérifier l’historique des scrubs et les erreurs courantes. Si vous avez déjà des erreurs de checksum, considérez cela comme en mode incident.
3. Stabiliser la plateforme. Si vous voyez des resets de lien ou des timeouts sur plusieurs disques, corrigez d’abord le transport.
4. Mettre offline le disque cible (s’il est présent) pour ne pas courir avec l’OS lors d’un hot-swap.
5. Remplacer par le chemin by-id persistant, pas /dev/sdX.
6. Surveiller le resilver et les métriques système. Le resilver peut saturer les I/O et rendre les applications malheureuses. C’est normal. La question : progresse-t-il de façon constante ?
7. Après achèvement, vérifier qu’aucune nouvelle erreur n’est apparue. Si les erreurs ont augmenté, n’« effacez » pas et n’oubliez pas — enquêtez, car le prochain scrub vous le rappellera.

Petite blague #2 : Le resilver RAIDZ, c’est comme regarder la peinture sécher, sauf que parfois la peinture peut prendre feu.

Pas à pas : augmenter la capacité avec des disques plus gros (sans se mentir)

Les upgrades de capacité sont l’endroit où les gens lancent accidentellement une « réalité mixte de stockage » : le pool rapporte une taille, le chassis en contient une autre, et tout le monde dispute des mathématiques. L’approche sûre est ennuyeuse : remplacer un disque à la fois, attendre le resilver, répéter, puis étendre.

La séquence ennuyeuse mais correcte

1. Remplacer un disque par un plus grand avec zpool replace.
2. Attendre la fin du resilver.
3. Répéter pour chaque disque du vdev.
4. Activer autoexpand si vous voulez que ZFS agrandisse automatiquement les vdevs quand possible.
5. Étendre le pool (souvent automatique après le dernier remplacement ; parfois nécessite online/expand selon la plateforme).

Tâche 17 : Vérifier le réglage autoexpand et l’activer si approprié

cr0x@server:~$ sudo zpool get autoexpand tank
NAME  PROPERTY    VALUE   SOURCE
tank  autoexpand  off     default

Signification : Autoexpand est actuellement off.

Décision : Si vous effectuez une montée en capacité et souhaitez que ZFS agrandisse automatiquement les vdevs quand tous les leaves sont plus grands, activez-le. Si vous n’êtes pas en upgrade planifié, laissez-le désactivé.

cr0x@server:~$ sudo zpool set autoexpand=on tank

Tâche 18 : Confirmer la taille du pool et l’allocation par vdev après les upgrades

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        29.1T  18.4T  10.7T        -         -    22%    63%  1.00x  ONLINE  -
  raidz2-0  29.1T  18.4T  10.7T        -         -    22%    63%      -  ONLINE  -

Signification : La taille du pool et des vdevs reflète maintenant la capacité étendue.

Décision : Si la taille n’a pas changé après tous les remplacements, vous devez probablement online/expand les devices, ou la partitionnement de la plateforme a laissé de l’espace inutilisé.

Tâche 19 : Mettre online et étendre un device leaf (si nécessaire)

cr0x@server:~$ sudo zpool online -e tank /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ0B555

Signification : L’option -e tente d’étendre le device pour utiliser l’espace disponible.

Décision : Utilisez ceci si vous avez remplacé par un disque plus grand et que ZFS n’a pas détecté la taille. Si le disque est partitionné et que la partition n’a pas été étendue, corrigez d’abord le partitionnement (hors portée de cet article ; point important : ZFS ne voit pas l’espace qu’il ne voit pas).

Playbook de diagnostic rapide (trouvez le goulot d’étranglement avant d’accuser ZFS)

Quand le resilver est lent, bloqué, ou fait que la machine rame, ne devinez pas. Faites un tri strict. L’objectif est de décider : est-ce un resilver lent normal, un conflit de charge, un disque frère défaillant, ou un problème de transport/contrôleur ?

Première étape : confirmer que ZFS progresse réellement

• Vérifier la ligne scan de zpool status : est-ce que « issued » augmente avec le temps ? Est-ce que « resilvered » augmente ?
• Décision : Si la progression est régulière, vous avez surtout un souci de tuning/planification. Si la progression stagne, vous avez une défaillance.

cr0x@server:~$ sudo zpool status tank | sed -n '1,20p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 24 10:14:02 2025
        2.61T scanned at 410M/s, 1.22T issued at 190M/s, 230G resilvered, 61.44% done, 02:31:20 to go

Deuxième étape : chercher les douleurs du transport (timeouts, resets, retries)

Les problèmes de transport imitent une panne de disque et ruinent les resilvers.

cr0x@server:~$ sudo dmesg -T | egrep -i "reset|timeout|link|frozen|SAS|phy|I/O error" | tail -n 40
[Wed Dec 24 11:02:41 2025] ata10: hard resetting link
[Wed Dec 24 11:02:46 2025] ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 24 11:03:10 2025] blk_update_request: I/O error, dev sdh, sector 987654321

Décision : Si des resets corrèlent avec des chutes de débit et affectent plusieurs disques, suspectez câble/backplane/HBA. Réparez cela d’abord. Remplacer un « autre disque » ne résoudra pas le problème.

Troisième étape : mesurer la saturation et l’ordonnancement au niveau device

cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server)   12/24/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.20   18.50    0.00   63.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sdg             98.0  101024.0     0.0   0.00   22.10  1030.9     12.0   1408.0   11.20   2.18   99.0
sdh             96.0   98624.0     0.0   0.00   21.80  1027.3     10.0   1280.0   10.90   2.10   98.5
sdj             30.0   9216.0      0.0   0.00   15.50   307.2     80.0  81920.0   35.10   3.90   99.3

Signification : Utilisation proche de 100% et temps d’attente élevés. Cela peut être normal pendant un resilver sur HDD, mais surveillez si un disque est un outlier.

Décision : Si un disque a un await beaucoup plus élevé ou des erreurs, c’est le candidat suivant à la panne — ou il est sur un mauvais port.

Quatrième étape : vérifier la latence et la pression de file côté ZFS

cr0x@server:~$ sudo zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        18.4T  10.7T    420    210   180M   92.0M
  raidz2-0  18.4T  10.7T    420    210   180M   92.0M
    sda         -      -     90     45   38.0M  20.0M
    sdb         -      -     85     40   36.0M  18.5M
    sdj         -      -     60     95   22.0M  38.0M
    sdd         -      -     92     15   40.0M  6.0M
    sde         -      -     93     15   44.0M  9.0M
----------  -----  -----  -----  -----  -----  -----

Décision : Si le nouveau disque est le hotspot d’écriture (commun), c’est attendu. Si la bande passante de lecture d’un ancien disque s’effondre, enquêtez sur ce disque et son lien.

Cinquième étape : décider de brider les charges ou de reporter

Si c’est une machine de production partagée, resilver plus des lectures aléatoires importantes est une taxe de performance. Parfois la bonne réponse est : brider ou déplacer des charges. ZFS ne peut pas négocier avec vos pics de trafic.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : le pool reste DEGRADED après le remplacement

Cause racine : Vous avez remplacé le mauvais leaf, utilisé le mauvais chemin de périphérique, ou le nouveau disque n’a pas été attaché au bon vdev.

Correction : Vérifiez zpool status -P. Confirmez que le leaf remplacé pointe maintenant vers le nouveau chemin by-id. Si vous voyez l’ancien et le nouveau, vous avez peut-être utilisé attach au lieu de replace. Corrigez la topologie intentionnellement.

2) Symptom : le resilver « tourne » mais ne se termine jamais (ETA qui grandit)

Cause racine : Erreurs de lecture ou resets de lien sur les disques survivants, ou nouveau disque qui droppe de façon intermittente.

Correction : Passez en revue dmesg pour resets/timeouts. Vérifiez les compteurs d’erreurs dans zpool status. Si des erreurs touchent plusieurs disques sur un même chemin, réparez le transport.

3) Symptom : cannot replace ... with ... ou « device is too small »

Cause racine : La capacité du disque de remplacement est légèrement plus petite (commun entre modèles/fournisseurs) ou la partition est plus petite que prévu.

Correction : Utilisez un disque d’égal ou plus grande capacité. Si partitionné, assurez-vous que la partition de remplacement correspond ou dépasse l’originale.

4) Symptom : le nouveau disque est ONLINE mais accumule immédiatement des erreurs d’écriture

Cause racine : Nouveau disque défectueux, lien SATA/SAS mauvais, ou problème de slot de backplane.

Correction : Déplacez le disque dans une autre baie si possible pour isoler slot vs disque. Lancez des tests SMART étendus si le temps le permet. Considérez les resets répétés comme un problème de plateforme, pas de ZFS.

5) Symptom : après « upgrade vers des disques plus gros », la taille du pool n’augmente pas

Cause racine : Tous les disques du vdev n’ont pas été upgradés, autoexpand est off, les devices leaf n’ont pas été étendus, ou les partitions n’ont pas été redimensionnées.

Correction : Vérifiez la taille de chaque leaf, activez autoexpand si souhaité, et utilisez zpool online -e quand c’est pris en charge. Confirmez les tailles de partition.

6) Symptom : le scrub trouve de nouvelles erreurs de checksum juste après le remplacement

Cause racine : Vous aviez une corruption latente ou un disque/câble marginal qui ne se manifestait qu’en lecture intensive.

Correction : Identifiez le vdev/disque qui montre les erreurs. Si les erreurs sont localisées, remplacez le disque. Si elles sont dispersées, explorez le contrôleur/backplane. N’« effacez » pas et ne passez pas à autre chose.

7) Symptom : vous avez remplacé un disque et maintenant le pool ne s’importe plus

Cause racine : Plusieurs disques ont été retirés/mis offline, mauvais disque retiré, ou vous avez dépassé la marge de redondance (surtout RAIDZ1). Parfois le contrôleur présente des IDs différents après un reboot.

Correction : Arrêtez. Préservez les preuves. Utilisez zpool import pour inspecter les pools importables et leur état. Évitez les flags force sauf si vous comprenez les transaction groups et ce que vous outrepassez.

Tâche 20 : Inspecter les pools importables quand la situation semble mauvaise

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: DEGRADED
status: One or more devices are missing from the system.
action: The pool can be imported despite missing or damaged devices.  The fault tolerance of the pool may be compromised.
config:

        tank                      DEGRADED
          raidz2-0                DEGRADED
            ata-WDC...VKJ0A123    ONLINE
            ata-WDC...VKJ0A124    ONLINE
            ata-WDC...VKJ0B555    ONLINE
            ata-WDC...VKJ0A126    ONLINE
            ata-WDC...VKJ0A127    UNAVAIL

Signification : ZFS voit le pool et peut probablement l’importer, mais un device est toujours manquant.

Décision : Ne forcez rien avant de savoir quel device physique manque et pourquoi.

Trois mini-histoires d’entreprise tirées du terrain

Incident causé par une mauvaise hypothèse : « Baie 12 est Baie 12 partout »

Une entreprise de taille moyenne exploitait une paire de serveurs de stockage dans deux racks, même modèle de chassis, même nombre de baies, pools en miroir pour quelques services. Une alerte de disque s’est déclenchée : zpool status montrait un numéro de série spécifique manquant. L’ingénieur on-call a fait la « chose normale » : demander aux facilities d’extraire la « Baie 12 » parce que les étiquettes du chassis indiquaient Baie 12.

Sauf qu’un chassis avait été entretenu des mois auparavant. Pendant ce service, le câblage du backplane avait été rerouté pour s’adapter à un mapping de ports HBA différent. Les étiquettes du chassis semblaient correctes ; le mapping derrière avait changé. « Baie 12 » dans l’UI n’était pas Baie 12 dans le métal.

Ils ont retiré un disque sain. Le pool est passé de DEGRADED à « vous avez un problème ». Heureusement c’était RAIDZ2, donc le service est resté up, mais le plan de resilver est devenu plus moche. Ils ont réinséré rapidement le mauvais disque — pourtant ZFS a enregistré une pluie d’erreurs due au retrait soudain sous charge.

Le post-mortem a été court et douloureux : la cause racine n’était pas ZFS. C’était un workflow humain qui se fiait au numéro de baie sans confirmer le serial. La correction fut simple : exiger la confirmation du serial avant retrait, et maintenir un document vivant par chassis (port HBA → expander → baie).

La leçon plus large : en production, « hardware identique » est un mythe. Les systèmes dérivent. Les gens oublient. Les étiquettes survivent plus longtemps que les vérités.

Optimisation qui s’est retournée contre eux : « Accélérons le resilver en augmentant la concurrence »

Une autre équipe avait un grand pool RAIDZ sur HDDs avec charges mixtes : lectures analytiques le jour, écritures de backup la nuit. Ils voulaient des resilvers plus rapides pour réduire les fenêtres de risque. Quelqu’un a trouvé des tunables promettant plus de débit en augmentant le parallélisme et en faisant « travailler plus les disques ».

Ils ont modifié quelques paramètres pendant les heures ouvrables — parce que le pool était déjà dégradé et « il faut que ça aille vite ». Le taux de resilver a bondi… brièvement. Puis la latence applicative a explosé. La machine a commencé à loguer des timeouts. Pas seulement sur le disque remplacé ; sur plusieurs disques.

Le vrai goulet n’était pas « ZFS n’essaie pas assez ». C’était le chemin HBA/expander et une profondeur de file qui est devenue pathologique sous les nouveaux réglages. Avec plus de concurrence, le système a transformé la latence transitoire en timeouts de commande, que ZFS a interprétés comme des erreurs de device. Le pool a passé du temps à réessayer et récupérer, au lieu de copier des données.

Ils ont rollbacké les tunables et ont plutôt limité la charge en déplaçant les jobs batch hors de l’hôte pendant le resilver. Le resilver a mis plus de temps que le pic idéal, mais il s’est terminé de façon fiable et le pool n’a pas accumulé de nouvelles erreurs.

Règle d’optimisation : si vous ne savez pas quel est le goulet, votre « tuning » n’est qu’une nouvelle façon d’avoir tort, plus rapidement.

Pratique ennuyeuse mais correcte qui a sauvé la mise : identifiants persistants et mains lentes

Un établissement financier exploitait des mirrors ZFS pour bases à faible latence et des RAIDZ2 pour backups. Leurs runbooks étaient stricts : tout retrait de disque requérait le nom de leaf ZFS, le chemin by-id, le numéro de série, et une seconde personne pour vérifier le numéro de série physique sur l’étiquette. Aucune exception, même à 3h du matin.

Une nuit, un disque a commencé à lancer des erreurs. L’on-call a suivi la procédure, a mis offline la leaf exacte, et le technicien a remplacé le bon disque. Le resilver a démarré. Puis, à mi-chemin, un autre disque sur le même backplane a commencé à montrer des resets de lien.

Voilà où la pratique ennuyeuse a payé : comme ils surveillaient les compteurs d’erreurs et dmesg pendant le resilver, ils ont reconnu tôt un problème de chemin partagé. Ils ont mis en pause les charges non essentielles et ont reseaté le câble du backplane pendant une fenêtre contrôlée. Les erreurs ont cessé. Le resilver s’est terminé proprement.

L’analyse a montré que le second disque allait bien. C’était le câble. S’ils avaient « optimisé » en remplaçant des disques à la chaîne pour chasser les alertes, ils auraient pu retirer un disque sain et dépasser la marge de redondance. Au lieu de cela, ils ont traité le système comme un système : disques, liens, et humains.

L’exploitation fiable, c’est surtout refuser d’être pressé exactement quand on en a le plus envie.

Listes de contrôle / plan étape par étape

Checklist A : Remplacement standard de disque (toute topologie)

1. Lancer zpool status -P ; copier l’identifiant de leaf exact et le chemin by-id.
2. Confirmer l’historique des scrubs et les erreurs actuelles. Si des erreurs de checksum existent, traiter comme risque élevé.
3. Vérifier les logs système (dmesg) pour des resets/timeouts affectant plusieurs disques.
4. Cartographier serial → baie physique ; confirmer avec les outils/étiquettes du chassis.
5. Mettre offline le disque cible (s’il est présent) avec zpool offline.
6. Remplacer le disque physique ; confirmer le numéro de série du nouveau disque dans l’OS.
7. Effacer les labels sur le nouveau disque : zpool labelclear -f.
8. Exécuter zpool replace en utilisant les chemins by-id.
9. Surveiller le resilver avec zpool status, zpool iostat, et les métriques OS.
10. Après achèvement, confirmer que le pool est ONLINE et que les compteurs d’erreurs sont stables.
11. Planifier un scrub si l’incident a impliqué des resets, des erreurs de checksum, ou plusieurs disques dysfonctionnels.
12. Clore la boucle : enregistrer ancien serial, nouveau serial, date, et changements de cartographie de baie.

Checklist B : Plan de confinement « j’ai peut‑être retiré le mauvais disque »

1. Arrêter d’ôter des disques. Remettre le disque retiré si possible.
2. Exécuter zpool status -P et prendre une capture de sortie pour les notes d’incident.
3. Vérifier la marge de redondance : RAIDZ1 avec deux disques manquants n’est pas un terrain pour expérimenter.
4. Utiliser l’identification par serial pour concilier ce qui manque vs ce qui a été retiré physiquement.
5. Si le pool est toujours importable, n’exportez/pas importez de façon répétée « pour voir si ça aide ». Stabilisez d’abord.
6. Ce n’est qu’une fois le système stable que vous procédez à un remplacement unique, vérifié, à la fois.

Checklist C : Montée en capacité (disques plus gros)

1. Confirmer la topologie vdev actuelle et l’ashift (pour ne pas upgrader vers de vieilles erreurs).
2. Vérifier que les disques de remplacement sont réellement plus grands (pas « marketing plus grands »).
3. Remplacer exactement un disque par vdev à la fois, attendre le resilver entre chaque opération.
4. Après remplacement de toutes les leaves d’un vdev, vérifier l’expansion (zpool list -v).
5. Utiliser zpool online -e si nécessaire et sûr.
6. Lancer un scrub après le remplacement final et l’expansion.

Tâche 21 : Mesurer la performance et la latence avant/après le remplacement (pour détecter des régressions)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        18.4T  10.7T    110     65   42.0M  18.0M
  raidz2-0  18.4T  10.7T    110     65   42.0M  18.0M
    sda         -      -     22     13   8.5M   3.0M
    sdb         -      -     20     12   7.9M   2.8M
    sdj         -      -     26     15   9.8M   4.0M
    sdd         -      -     21     12   8.1M   4.1M
    sde         -      -     21     13   7.7M   4.1M
----------  -----  -----  -----  -----  -----  -----

Signification : Établit un profil de base. Si un disque devient lent après remplacement, c’est ici que vous le verrez.

Décision : Si le nouveau disque sous‑performe massivement par rapport aux pairs, suspectez des particularités SMR, comportement de firmware, ou un mauvais lien/port.

Tâche 22 : Lancer un scrub post-remplacement (vérification planifiée)

cr0x@server:~$ sudo zpool scrub tank

Signification : Lance une vérification d’intégrité complète. Sur de grands pools, cela peut prendre des heures.

Décision : Planifiez‑le pendant une fenêtre plus calme si la charge est sensible à la latence ; surveillez les erreurs et l’impact de performance.

Tâche 23 : Vérifier les résultats du scrub et prendre la décision « ship it »

cr0x@server:~$ sudo zpool status tank | sed -n '1,15p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:41:08 with 0 errors on Thu Dec 25 02:01:33 2025

Signification : Le scrub n’a rien trouvé ni réparé, avec zéro erreur. C’est la chose la plus proche d’une clôture.

Décision : Clore l’incident/change. Si des erreurs ont été trouvées, continuez l’investigation ; quelque chose dysfonctionne encore.

FAQ

1) Dois‑je toujours mettre un disque offline avant de le retirer ?

Oui, quand le disque est encore présent et que vous contrôlez le moment. L’offline réduit les erreurs I/O surprises et transforme le retrait en une modification d’état intentionnelle. Si le disque a déjà disparu, l’offline n’aidera pas, mais il ne réparera rien non plus.

2) Quelle est la différence entre « resilver » et « scrub » ?

Le resilver reconstruit des données vers un device de remplacement pour restaurer la redondance. Le scrub vérifie l’ensemble du pool via les checksums et répare à l’aide de la redondance quand c’est possible. Resilver = récupération ciblée ; scrub = audit complet du pool.

3) Puis‑je remplacer plusieurs disques en même temps ?

Vous pouvez, mais généralement vous ne devriez pas. Un par un garde le système dans un état connu et évite de dépasser accidentellement les limites de redondance. L’exception : vous avez des spares pré‑attachés dans certains designs, ou une panne de backplane vous force à plusieurs changements — alors vous opérez en mode incident avec acceptation explicite du risque.

4) Dois‑je utiliser les chemins /dev/sdX dans zpool replace ?

Non. Utilisez /dev/disk/by-id/... (ou l’équivalent stable sur votre OS). /dev/sdX est un détail d’implémentation qui change au reboot, au rescans, et parfois juste parce que le noyau en a eu envie.

5) Mon nouveau disque est « le même modèle » mais légèrement plus petit. Pourquoi ?

Parce que les fournisseurs révisent le firmware, utilisent des plateaux différents, ou réservent des espaces différents. ZFS est strict : le remplacement doit être égal ou plus grand. Gardez quelques spares « connus bons et assez grands » plutôt que de faire confiance à la capacité marketing.

6) Pourquoi la vitesse de resilver diffère‑t‑elle tant d’une simple copie disque→disque ?

ZFS ne copie pas des blocs bruts depuis une seule source. Il reconstruit à partir de la redondance, lit à travers les membres du vdev, valide les checksums, et concurrence avec des charges live. Aussi, les pools fragmentés résilver plus lentement parce que les métadonnées et les blocs sont dispersés.

7) Après remplacement, puis‑je simplement lancer zpool clear pour réinitialiser les erreurs ?

Vous pouvez effacer après avoir corrigé la cause sous‑jacente et si vous voulez surveiller une récidive. N’effacez pas en guise de substitution à l’investigation. Les compteurs d’erreurs sont des preuves, et les preuves sont utiles.

8) Dois‑je partitionner les disques pour ZFS ?

Ça dépend des conventions de votre plateforme et des besoins de boot. Beaucoup de déploiements Linux utilisent les disques entiers ; d’autres utilisent des partitions pour l’alignement ou les outils. Opérationnellement, la cohérence compte plus que l’idéologie : ne mélangez pas les approches sans précaution et assurez‑vous que les remplacements correspondent au schéma existant.

9) Qu’en est‑il des hot spares — devrais‑je en utiliser ?

Les hot spares peuvent réduire le temps jusqu’au resilver, ce qui diminue le risque. Mais ils peuvent aussi masquer des problèmes d’hygiène opérationnelle (vous devez toujours remplacer physiquement le disque défaillant) et peuvent être consommés par le mauvais mode de panne (comme un expander flaky provoquant plusieurs « pannes »). Utilisez‑les, mais ne laissez pas cela remplacer la surveillance et la discipline.

10) RAIDZ1 est‑il acceptable si je remplace rapidement les disques ?

Parfois, pour des données peu critiques et des petits pools. En production, RAIDZ1 avec de grands disques et des charges réalistes est une décision de risque, pas une astuce technique. Le remplacement de disques est exactement le moment où vous découvrez à quel point vous regrettez cette décision.

Clôture : étapes pratiques suivantes

Si vous voulez moins d’incidents de remplacement de disques ZFS — et moins de matins « pourquoi le pool est encore en colère ? » — faites du workflow sûr votre valeur par défaut :

• Standardisez les noms de périphériques persistants dans les configs de pool et les runbooks.
• Exigez la confirmation du serial avant tout retrait physique. Vérification à deux personnes si les données comptent.
• Offlinez intentionnellement, remplacez avec zpool replace, et surveillez le resilver comme une migration live — parce que c’en est une.
• Quand le resilver est lent, diagnostiquez d’abord le transport et les disques frères. ZFS rapporte généralement des symptômes, il ne hallucine pas.
• Terminez par un scrub quand l’incident a eu la moindre odeur d’instabilité. C’est la piste d’audit que votre vous futur vous remerciera d’avoir.

Faites cela de manière cohérente et les remplacements de disques redeviennent ce qu’ils devraient être : de la maintenance, pas du théâtre.