L’alerte arrive à 09:12 : « DEGRADED pool. » Vous remplacez le disque, lancez zpool replace et vous vous attendez à quelques heures d’activité.
Puis zpool status vous annonce « resilvering… 3% » et une ETA qui ressemble à un long week-end.
Le temps de resilver n’est pas une faiblesse morale. C’est de la physique, de la profondeur de file d’attente, de la géométrie des vdev et la réalité gênante que les charges de production ne s’arrêtent pas parce que vous le souhaitez.
L’astuce est de savoir quels leviers sont sûrs, lesquels sont du cargo-cult et lesquels échangent vitesse aujourd’hui contre perte de données demain.
Ce que fait réellement le resilver (et pourquoi il semble plus lent qu’il « devrait »)
Dans ZFS, un « resilver » est la reconstruction après qu’un périphérique a été remplacé ou est revenu en ligne. ZFS parcourt les métadonnées du pool pour découvrir quels blocs sont réellement utilisés,
puis régénère les copies/parités manquantes et les écrit sur le nouveau périphérique (ou celui revenu).
Cette partie « parcourir les métadonnées » explique pourquoi le resilver n’est souvent pas une simple copie linéaire des « octets utilisés ». C’est une chaîne de dépendances :
ZFS doit lire les métadonnées pour savoir où se trouvent les blocs de données, puis lire ces blocs, puis écrire les blocs reconstruits, tout en restant cohérent avec les écritures en cours.
Si votre pool est fragmenté, riche en métadonnées ou sous charge, le resilver devient un festival de seek et de queues.
De plus, resilver n’est pas juste un gros flux de lecture et d’écriture. C’est « trouver tous les blocs référencés et réparer le côté manquant », ce qui en RAIDZ impose de lire suffisamment
de colonnes pour reconstruire la parité, et en miroir signifie copier les blocs de l’autre côté. Les miroirs peuvent être rapides si les lectures sont séquentielles. RAIDZ souvent ne le sont pas.
Une réalité opérationnelle supplémentaire : ZFS essaie d’être un bon voisin. Par défaut il ne va pas évincer vos charges de production pour faire le travail à votre place.
Le resilver concurrence tout le reste pour l’I/O, et ZFS laisse intentionnellement de la marge—à moins que vous ne lui disiez le contraire.
Pourquoi un resilver prend des jours : les véritables goulots d’étranglement
1) I/O aléatoire et fragmentation : vos « octets utilisés » ne sont pas contigus
Si votre pool fonctionne depuis des années avec des charges mixtes—images VM, bases de données, petits fichiers, suppressions, snapshots—les blocs se dispersent.
ZFS doit suivre des pointeurs de métadonnées, ce qui se traduit par beaucoup de petites lectures. Les HDD détestent ça. Même les SSD peuvent peiner si vous les saturez par des désaccords de profondeur de file d’attente
ou si vous entraînez une amplification d’écriture.
Le mensonge que l’on se raconte est : « Il n’y a que 12 To utilisés ; ça devrait resilver en 12 To / débit disque. » Cela suppose des lectures/écritures séquentielles, peu de surcharge de métadonnées,
et aucune contention. En réalité, le débit effectif du resilver est souvent limité par les IOPS, pas par les MB/s.
2) Géométrie des vdev : la reconstruction RAIDZ lit plus que vous ne le pensez
Dans un miroir, pour reconstruire un côté manquant vous pouvez en général lire le disque sain et écrire le nouveau disque. En RAIDZ, pour reconstruire un disque manquant,
ZFS lit les colonnes restantes de chaque stripe. C’est plus d’I/O par octet reconstruit, et c’est dispersé sur davantage de plateaux.
Le resilver RAIDZ peut être particulièrement pénible sur des vdev larges avec de gros disques. Le pool est dégradé, donc la redondance est réduite, et les performances chutent exactement quand vous en avez besoin.
Si vous êtes malchanceux, vous servirez aussi des lectures de production avec moins de colonnes disponibles. C’est comme reconstruire un pont pendant l’heure de pointe.
3) « Allocation pendant le resilver » : les blocs bougent sous vos pieds
ZFS est copy-on-write. Les nouvelles écritures vont vers de nouveaux emplacements, les anciens blocs restent référencés jusqu’à ce qu’ils soient libérés. Pendant le resilver, les écritures actives peuvent changer ce qui doit être copié :
mises à jour de métadonnées, blocs indirects, nouveaux pointeurs de blocs. ZFS gère cela, mais cela signifie que l’opération est moins « passe unique » que ce que l’on suppose.
4) Remplissage du pool : au-delà d’environ 80% ça devient vite moche
Les pools pleins se fragmentent davantage, allouent en morceaux plus petits, et forcent ZFS à travailler plus dur pour trouver de l’espace. Le resilver devient plus aléatoire, et la surcharge augmente.
Si vous avez aussi beaucoup de snapshots, l’espace libéré n’est pas vraiment libre tant que les snapshots n’expirent pas, donc « df indique 20% libres » peut être une fiction.
5) Recordsize, volblocksize et charges à petits blocs
Le resilver doit gérer vos tailles de blocs telles qu’elles existent sur disque. Un zvol VM avec volblocksize 8K ou un dataset base de données avec recordsize 16K
se traduit par beaucoup plus de blocs à parcourir qu’un dataset rempli de records de 1M.
Plus de blocs signifie plus de métadonnées, plus de checksums, plus d’opérations I/O, et moins de chance d’avoir de jolis motifs séquentiels. Vous ne remarquez pas cela au quotidien
jusqu’au moment de la reconstruction.
6) Compression et dedup : super jusqu’à la reconstruction
La compression aide généralement le resilver parce que moins d’octets doivent être lus et écrits—si le CPU n’est pas le goulot.
La dédup est l’inverse : elle ajoute des recherches de métadonnées et rend souvent tout plus aléatoire.
Si vous avez activé dedup parce que vous avez vu un jour une slide sur « efficacité de stockage », vous vous êtes construit une taxe de resilver. Elle se cumule sous pression.
7) Checksumming, chiffrement et goulots CPU
ZFS vérifie les checksums lors des lectures. Si vous utilisez le chiffrement natif, il déchiffre aussi. Sur des CPU anciens ou des machines sollicitées, le resilver peut devenir lié au CPU,
surtout quand le pattern I/O comporte beaucoup de petits blocs (plus d’opérations de checksum par octet).
8) « Priorité du resilver » est un compromis, pas un miracle gratuit
Vous pouvez souvent accélérer le resilver en lui laissant consommer plus d’I/O. Cela accélère la récupération mais peut écraser la latence de vos applications.
L’accélération sûre est celle qui maintient vos SLO.
9) Disques de remplacement lents ou mal assortis
Si le nouveau disque est SMR, a une GC interne agressive, est connecté via un HBA médiocre, ou est simplement plus lent que l’ancien,
le temps de resilver peut exploser. « Même capacité » n’est pas « même comportement ».
Blague #1 : Le resilver, c’est l’équivalent stockage de repeindre sa maison en y habitant toujours — tout est techniquement possible, juste peu agréable.
Faits intéressants & historique (parce que le passé explique la douleur)
- ZFS a commencé chez Sun Microsystems au milieu des années 2000 en réaction aux systèmes de fichiers qui traitaient « gestion de volume » et « système de fichiers » séparément.
- Copy-on-write était un pari délibéré : il a rendu les snapshots peu coûteux et la cohérence forte, mais il a aussi rendu les schémas d’allocation plus complexes avec le temps.
- Resilver n’est pas un scrub : scrub valide l’intégralité du pool ; resilver reconstruit la redondance après perte d’un périphérique. Ils partagent des chemins de code mais ont des intentions différentes.
- L’espace « slop » existe pour une raison : ZFS garde un peu d’espace non allouable pour éviter la fragmentation catastrophique et les échecs d’allocation sur des pools presque pleins.
- L’expansion RAIDZ était historiquement limitée (étendre un vdev RAIDZ en ajoutant des disques) ce qui a poussé beaucoup d’équipes vers des vdev larges dès le départ — parfait au jour 1, stressant au jour 900.
- Les disques SMR ont changé la donne : ils peuvent paraître corrects en benchmarks et s’effondrer ensuite sous des écritures aléatoires soutenues comme le trafic de resilver.
- OpenZFS est devenu le centre de gravité après Sun, avec plusieurs plateformes (illumos, FreeBSD, Linux) portant la torche et divergeant sur des paramètres réglables.
- Des améliorations pour un resilver séquentiel ont été ajoutées au fil du temps pour accélérer certains motifs, mais elles ne peuvent pas undo la fragmentation ni corriger « pool à 92% plein » comme choix de vie.
Playbook de diagnostic rapide : trouver le goulot en 10 minutes
Quand le resilver est lent, ne devinez pas. Prenez trois mesures : ce que ZFS pense faire, ce que font les disques, et ce que font le CPU et la mémoire.
Puis décidez d’accélérer le resilver ou de réduire la charge de production—ou les deux.
First: confirm the rebuild is real and see the shape of it
- Vérifiez
zpool statuspour le taux de scan, les erreurs, et si c’est un resilver ou un scrub. - Confirmez quel vdev est affecté et si vous êtes en RAIDZ ou miroir.
- Cherchez des progrès du type « resilvered X in Y » ; si ça bouge à peine, vous êtes probablement lié par les IOPS ou bloqué par des erreurs/retries.
Second: identify the limiting resource (IOPS, bandwidth, CPU, or contention)
- Disque occupé mais faible débit : I/O aléatoire / mise en file / SMR / retries.
- CPU élevé dans les threads kernel/ZFS : checksum/chiffrement/workload riche en métadonnées.
- Pics de latence dans les applis : resilver qui concurrence l’I/O de production ; ajustez les priorités ou planifiez une réduction de charge.
Third: decide on the safe intervention
- Si la production est calme, augmentez l’agressivité du resilver légèrement et surveillez la latence.
- Si la production en souffre, réduisez l’impact du resilver et acceptez une reconstruction plus longue—sauf si le risque dicte le contraire.
- Si un périphérique génère des erreurs, arrêtez de « tuner » et commencez le diagnostic matériel/câblage.
Tâches pratiques : commandes, sorties et décisions (12+)
Voici les contrôles que j’exécute réellement. Chacun inclut ce que signifie la sortie et la décision qui en découle.
Les commandes sont montrées comme si vous êtes sur une machine Linux avec OpenZFS ; adaptez les chemins si vous êtes sur illumos/FreeBSD.
Task 1: Confirm scan state, speed, and whether you’re resilvering or scrubbing
cr0x@server:~$ zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Dec 23 09:12:11 2025
1.87T scanned at 58.3M/s, 612G issued at 19.1M/s, 22.4T total
102G resilvered, 2.91% done, 5 days 03:18:22 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
sdh ONLINE 0 0 0
sdi ONLINE 0 0 0
sdj ONLINE 0 0 0
sdk ONLINE 0 0 0
sdl ONLINE 0 0 0
sdm ONLINE 0 0 0
sdn ONLINE 0 0 0
sdo ONLINE 0 0 0
sdp ONLINE 0 0 0
sdq ONLINE 0 0 0
sdr ONLINE 0 0 0
sds ONLINE 0 0 0
sdt ONLINE 0 0 0
sdu ONLINE 0 0 0
sdv ONLINE 0 0 0
sdx ONLINE 0 0 0
sdy ONLINE 0 0 0
sdz ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdab ONLINE 0 0 0
sdac ONLINE 0 0 0
sdad ONLINE 0 0 0
sdae ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdag ONLINE 0 0 0
sdah ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdak ONLINE 0 0 0
sdal ONLINE 0 0 0
sdam ONLINE 0 0 0
sdan ONLINE 0 0 0
sdao ONLINE 0 0 0
sdap ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdar ONLINE 0 0 0
sdas ONLINE 0 0 0
sdat ONLINE 0 0 0
sdau ONLINE 0 0 0
sdav ONLINE 0 0 0
sdaw ONLINE 0 0 0
sdax ONLINE 0 0 0
sday ONLINE 0 0 0
sdaz ONLINE 0 0 0
sdba ONLINE 0 0 0
sdbb ONLINE 0 0 0
sdbc ONLINE 0 0 0
sdbd ONLINE 0 0 0
sdbe ONLINE 0 0 0
sdbf ONLINE 0 0 0
sdbg ONLINE 0 0 0
sdbh ONLINE 0 0 0
sdbi ONLINE 0 0 0
sdbj ONLINE 0 0 0
sdbk ONLINE 0 0 0
sdbl ONLINE 0 0 0
sdbm ONLINE 0 0 0
sdbn ONLINE 0 0 0
sdbo ONLINE 0 0 0
sdbp ONLINE 0 0 0
sdbq ONLINE 0 0 0
sdbr ONLINE 0 0 0
sdbs ONLINE 0 0 0
sdbt ONLINE 0 0 0
sdbu ONLINE 0 0 0
sdbv ONLINE 0 0 0
sdbw ONLINE 0 0 0
sdbx ONLINE 0 0 0
sdby ONLINE 0 0 0
sdbz ONLINE 0 0 0
sdcA ONLINE 0 0 0
sdcB ONLINE 0 0 0
sdcC ONLINE 0 0 0
sdcD ONLINE 0 0 0
sdcE ONLINE 0 0 0
sdcF ONLINE 0 0 0
sdcG ONLINE 0 0 0
sdcH ONLINE 0 0 0
sdcI ONLINE 0 0 0
sdcJ ONLINE 0 0 0
sdcK ONLINE 0 0 0
sdcL ONLINE 0 0 0
sdcM ONLINE 0 0 0
sdcN ONLINE 0 0 0
sdcO ONLINE 0 0 0
sdcP ONLINE 0 0 0
sdcQ ONLINE 0 0 0
sdcR ONLINE 0 0 0
sdcS ONLINE 0 0 0
sdcT ONLINE 0 0 0
sdcU ONLINE 0 0 0
sdcV ONLINE 0 0 0
sdcW ONLINE 0 0 0
sdcX ONLINE 0 0 0
sdcY ONLINE 0 0 0
sdcZ ONLINE 0 0 0
sdd0 ONLINE 0 0 0
errors: No known data errors
Ce que cela signifie : « scanned » vs « issued » vous indique le parcours des métadonnées vs l’I/O de reconstruction réelle.
Si « issued » est bien inférieur à « scanned », vous passez du temps à parcourir les métadonnées et/ou vous êtes bridés par les IOPS.
Décision : Si l’ETA est en jours et que votre pool est grand, ne paniquez pas encore. Passez aux vérifications de goulot ci-dessous avant de toucher aux réglages.
Task 2: Check pool health and error trends (don’t tune around dying hardware)
cr0x@server:~$ zpool status -x
pool 'tank' is degradedCe que cela signifie : Le pool n’est pas sain ; le resilver est attendu. Si vous voyez des erreurs supplémentaires (READ/WRITE/CKSUM), c’est plus urgent.
Décision : Si les erreurs augmentent pendant le resilver, arrêtez le « travail de performance » et commencez le « triage matériel ».
Task 3: Confirm which disk is new and whether it negotiated correctly (link speed, size)
cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,ROTA,TYPE /dev/sdx
NAME SIZE MODEL SERIAL ROTA TYPE
sdx 14.6T ST16000NM000J ZR12ABCDEF 1 diskCe que cela signifie : Vous voulez que le remplacement corresponde à la capacité attendue et soit un modèle CMR entreprise, pas un disque desktop SMR surprise.
Décision : Si model/serial semble incorrect, arrêtez et validez l’achat. Le « correctif » le moins coûteux est de retourner le mauvais disque avant qu’il ne vous fasse perdre la semaine.
Task 4: Spot SMR behavior or deep write stalls using iostat
cr0x@server:~$ iostat -x 2 5 /dev/sdx
Linux 6.6.0 (server) 12/25/2025 _x86_64_ (32 CPU)
Device r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdx 12.0 180.0 1.1 9.4 116.0 27.8 145.2 8.1 154.8 2.9 56.8
sdx 11.5 190.5 1.0 2.2 36.2 64.1 336.7 9.2 356.8 2.7 52.4
Ce que cela signifie : L’augmentation de await avec effondrement de wMB/s est un comportement classique de « disque qui plante ».
Pas toujours SMR, mais souvent « le firmware du disque réorganise les écritures » ou vous avez un problème de transport/HBA.
Décision : Si le périphérique de remplacement a un await pathologique, déplacez-le vers une autre baie/câble/port HBA ou remplacez le modèle de disque.
Task 5: See if resilver is IOPS-bound across the vdev
cr0x@server:~$ iostat -x 2 3
Device r/s w/s rMB/s wMB/s avgqu-sz await %util
sda 85.0 22.0 5.1 1.2 9.2 86.4 92.0
sdb 82.0 25.0 4.9 1.4 8.7 84.9 90.1
sdc 83.0 23.0 5.0 1.3 9.1 85.7 91.5Ce que cela signifie : Un %util élevé avec peu de MB/s signifie que vous ne streamez pas ; vous cherchez. C’est pourquoi le calcul « disque 14 To à 250 MB/s » échoue.
Décision : Ne montez pas les boutons « vitesse resilver » en vous attendant à des miracles. Vous devez réduire la pression I/O aléatoire (mettre les charges en pause, réduire le churn de snapshots),
ou accepter le calendrier.
Task 6: Check ARC pressure and whether the box is thrashing
cr0x@server:~$ arcstat 2 5
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
09:23:01 914 202 22 46 23 156 77 0 0 96G 112G
09:23:03 901 229 25 51 22 178 78 0 0 96G 112G
09:23:05 938 301 32 90 29 211 70 0 0 96G 112GCe que cela signifie : L’augmentation des misses pendant le resilver peut vouloir dire que les métadonnées ne tiennent pas bien, ou que la production + resilver dépasse l’utilité du cache.
Décision : Si l’ARC est contraint et que vous swappez, arrêtez : la pression mémoire va détruire le resilver et tout le reste. Ajoutez de la RAM ou réduisez la charge.
Task 7: Confirm you are not swapping (swapping turns rebuild into a slow-motion disaster)
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 82432 12644 9812448 0 0 4920 1280 4200 6100 18 12 58 12 0
2 0 0 80120 12644 9812016 0 0 5100 1320 4302 6230 17 11 57 15 0
Ce que cela signifie : si/so devraient être zéro. Si vous swappez, les parcours de métadonnées ZFS et le travail de checksum vont se traîner.
Décision : Si swap présent, réduisez la cap d’ARC, arrêtez les gourmands en mémoire, ou déplacez les charges. Ne dites pas « laissez finir ».
Task 8: Check whether a scrub is running concurrently (and stop it if it’s not policy-critical)
cr0x@server:~$ zpool status tank | sed -n '1,20p'
pool: tank
state: DEGRADED
scan: scrub in progress since Mon Dec 23 08:55:02 2025
3.11T scanned at 72.5M/s, 901G issued at 21.0M/s, 22.4T total
0B repaired, 4.03% done, 2 days 22:10:05 to goCe que cela signifie : Un scrub en concurrence avec un resilver est généralement de l’autosabotage sauf raison spécifique.
Décision : Si le pool est déjà dégradé et que vous essayez de restaurer la redondance, priorisez le resilver et mettez le scrub en pause.
cr0x@server:~$ sudo zpool scrub -s tank
scrub stoppedTask 9: Verify autotrim and ashift assumptions (performance cliffs hide here)
cr0x@server:~$ zdb -C tank | egrep -i 'ashift|autotrim'
ashift: 12
autotrim: off
Ce que cela signifie : ashift définit l’alignement secteur. Un ashift incorrect peut réduire irrémédiablement les performances d’écriture.
autotrim importe surtout pour les pools SSD.
Décision : Vous ne pouvez pas changer ashift en place. S’il est mauvais, planifiez une migration. Ne prétendez pas qu’un réglage corrigera la géométrie.
Task 10: Check dataset-level properties that amplify resilver work
cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,dedup,atime tank/vmstore
NAME PROPERTY VALUE
tank/vmstore recordsize 128K
tank/vmstore compression lz4
tank/vmstore dedup off
tank/vmstore atime offCe que cela signifie : recordsize petit, dedup=on, et atime=on (pour datasets très actifs) peuvent augmenter le churn de métadonnées et le travail de reconstruction.
Décision : Ne changez pas ces paramètres en plein resilver comme « astuce de vitesse ». Servez-vous en pour concevoir à l’avenir et pour cibler les charges à limiter.
Task 11: Identify whether special vdev or metadata devices are the bottleneck
cr0x@server:~$ zpool status tank | sed -n '1,120p'
pool: tank
state: DEGRADED
scan: resilver in progress since Mon Dec 23 09:12:11 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
...
special
mirror-1 ONLINE 0 0 0
nvme0n1 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0Ce que cela signifie : Si vous avez un special vdev (métadonnées/petits blocs), ses performances peuvent dominer la vitesse du resilver parce que le resilver est riche en métadonnées.
Décision : Surveillez la latence et la santé des NVMe ; un vdev de données « correct » peut toujours resilver lentement si les dispositifs de métadonnées sont saturés ou dégradés.
Task 12: Check for I/O errors and retries in kernel logs (silent killer)
cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]|scsi|reset|I/O error|blk_update_request' | tail -n 12
[Tue Dec 23 10:02:14 2025] sd 3:0:8:0: [sdx] tag#83 I/O error, dev sdx, sector 1883742336 op 0x1:(WRITE) flags 0x0 phys_seg 16 prio class 0
[Tue Dec 23 10:02:15 2025] ata9: hard resetting link
[Tue Dec 23 10:02:20 2025] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)Ce que cela signifie : Les reset de lien et la négociation à vitesse dégradée (1.5 Gbps) vont étirer le resilver jusqu’à des temps géologiques.
Décision : Réparez le câblage/backplane/HBA. Ne réglez pas ZFS pour compenser un transport instable.
Task 13: See if ZFS is throttling resilver due to tunables (and adjust carefully)
cr0x@server:~$ sudo sysctl -a 2>/dev/null | egrep 'zfs_vdev_resilver|zfs_resilver|scan_idle'
debug.zfs_scan_idle=50
debug.zfs_vdev_resilver_max_active=2
debug.zfs_vdev_resilver_min_active=1
Ce que cela signifie : Ces boutons influencent à quel point ZFS envoie des I/O pour le resilver et combien il idle pour favoriser la production.
Les noms varient selon plateforme/distribution ; ne copiez-collez pas des valeurs de blog sans réfléchir.
Décision : Si vous avez de la marge I/O et une latence acceptable, augmentez max_active modestement. Si la latence est déjà mauvaise, ne le faites pas.
Task 14: Verify the pool isn’t dangerously full (full pools rebuild slowly and fail creatively)
cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -p tank | head
NAME USED AVAIL REFER MOUNTPOINT
tank 19854735163392 2533274798080 1048576 /tankCe que cela signifie : Environ 19.8 To utilisés, 2.5 To disponibles. Sur un pool ~22 To, c’est flirt avec la zone dangereuse.
Décision : Si vous êtes au-dessus d’environ 80–85% et que le resilver est lent, priorisez la libération d’espace (supprimez vieux snapshots, déplacez les données froides) avant de tuner pour la vitesse.
Façons sûres d’accélérer le resilver (ce qui marche, ce qui ne marche pas)
L’objectif n’est pas « rendre le resilver rapide ». L’objectif est « restaurer la redondance rapidement sans écraser la production ou corrompre les données ».
Ce ne sont pas la même chose. Vous pouvez toujours rendre les choses rapides en les faisant mal.
1) Réduire l’I/O concurrente (le mouvement peu sexy mais le plus efficace)
Si le resilver est lié aux IOPS, la meilleure action est d’arrêter de générer de l’I/O aléatoire. Cela signifie généralement :
- Mettre en pause les jobs batch : sauvegardes, réindexation de logs, analytics, gros rsync.
- Limiter ou migrer les locataires bruyants (les clusters de VM sont célèbres pour ça).
- Différer la suppression de snapshots qui déclenche beaucoup de frees/rewrites (dépend de l’implémentation et de la charge).
C’est souvent politiquement difficile. Ça ne devrait pas l’être. Un pool dégradé est un événement de risque. Traitez-le comme tel.
2) Augmenter l’agressivité du resilver—prudemment, avec un plan de rollback
Les réglages ZFS qui contrôlent la concurrence du scan/resilver peuvent augmenter le débit. Ils peuvent aussi augmenter la latence et déclencher des timeouts dans des applis sensibles.
Ajustez par petites étapes, mesurez, et revenez en arrière si la douleur dépasse le gain.
cr0x@server:~$ sudo sysctl -w debug.zfs_scan_idle=0
debug.zfs_scan_idle = 0Ce que cela signifie : Réduire le temps idle veut dire que le travail de scan cède moins la place à l’I/O normale. Le resilver obtient plus de tours.
Décision : Utilisez ceci seulement si vous pouvez tolérer une latence plus élevée, et surveillez immédiatement les SLO applicatifs. Si la latence explose, remettez à la valeur précédente.
cr0x@server:~$ sudo sysctl -w debug.zfs_vdev_resilver_max_active=4
debug.zfs_vdev_resilver_max_active = 4Ce que cela signifie : Plus d’opérations I/O concurrentes par vdev. Bon pour des systèmes sous-utilisés, mauvais pour des plateaux déjà saturés.
Décision : Si les disques montrent faible %util et faible profondeur de file d’attente, cela peut aider. Si les disques sont déjà au taquet, cela n’augmentera que la latence.
3) Mettre le disque de remplacement sur le meilleur chemin (HBA, firmware, câblage)
La vérité ennuyeuse : la vitesse du resilver est souvent limitée par un seul lien qui se comporte mal. Un disque sur SATA à 1.5 Gbps, ou un port HBA qui vacille,
peut tirer un resilver RAIDZ vers le bas parce que la reconstruction de parité attend les retardataires.
Réparez la couche physique. Puis tunez.
4) Préférer les miroirs quand le temps de rebuild compte plus que la capacité
Si vous concevez des systèmes où le temps de rebuild en cas de panne est un risque majeur, les miroirs sont vos amis. Ils resilvent en copianto les blocs alloués du côté sain.
Dans de nombreuses déploiements réels, les miroirs offrent aussi des performances plus prévisibles en cas de défaillance partielle.
RAIDZ est correct—parfois excellent—mais ne prétendez pas que c’est « pareil et moins cher ». Pendant le resilver, c’est une bête différente.
5) Garder les pools moins pleins (votre futur vous remerciera)
La façon la plus simple d’accélérer un resilver est d’éviter la fragmentation pathologique. Le prédicteur le plus fiable de la fragmentation dans l’univers ZFS est :
combien près du remplissage vous maintenez le pool.
Mettez des quotas. Faites-les respecter. Ayez un plan de capacité. « On nettoiera après » est la façon d’obtenir des resilvers de 5 jours et des réunions à 2h du matin.
6) Utiliser des tailles de blocs sensées pour la charge (avant l’incident, pas pendant)
Pour les stockages VM, choisissez volblocksize avec intention. Pour les datasets, choisissez recordsize aligné sur la charge. Il ne s’agit pas d’optimiser des benchmarks ;
il s’agit de réduire le nombre de métadonnées et de blocs pour que le travail de reconstruction évolue de façon raisonnable.
7) Ne pas « optimiser » en désactivant les checksums ou en faisant confiance au hasard
Les checksums ne sont pas des ceintures de sécurité optionnelles. Le resilver est précisément le moment où vous voulez l’intégrité bout en bout.
ZFS ne vous donne pas de voie supportée et sensée pour « sauter la vérification pour la vitesse », et c’est une fonctionnalité, pas une limitation.
Blague #2 : Tourner des boutons pendant un resilver sans mesurer, c’est comme ajouter plus de café pour réparer une imprimante en panne—satisfaisant émotionnellement, techniquement sans rapport.
Une citation à garder sur votre pont d’incident
« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent citée en ingénierie et opérations
La version opérationnelle : mesurez d’abord, changez une chose, mesurez encore. Tout le reste est de la performance cosplay.
Trois mini-récits d’entreprise depuis le terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise SaaS de taille moyenne faisait tourner un cluster VM sur ZFS sur un vdev RAIDZ2 large. Ça fonctionnait « bien » depuis des années. Un disque a lâché un mardi.
L’on-call l’a remplacé rapidement et a lancé le replace. Tout le monde s’est détendu.
L’hypothèse : « Le resilver ne copie que les données utilisées, donc ce sera plus rapide qu’une reconstruction complète. » Le pool était à environ 60% d’utilisation.
Ils ont fait le calcul classique sur un coin de serviette en utilisant le débit séquentiel et ont décidé que le resilver finirait pendant la nuit.
La nuit est passée et le progrès est resté bloqué à un pourcentage à un chiffre. La latence pour les VMs clients a grimpé par intermittence, et l’infrastructure hyperviseur a commencé à journaliser des timeouts d’I/O invités.
L’équipe a réagi en ajoutant plus de charge—spécifiquement en migrant des VMs pour « équilibrer ». Ces migrations étaient des lectures/écritures aléatoires. Elles ont mis de l’huile sur le feu.
Le vrai problème : le pool était vieux, chargé de snapshots et fortement fragmenté. Le resilver était limité par les IOPS, pas par la bande passante. Chaque mitigation « bouger vite » a empiré le pattern I/O.
Après 36 heures, un second disque a signalé des erreurs. Ce n’était plus un rebuild lent ; c’était un incident à risque de données.
Ils ont récupéré, mais la leçon est restée : le temps de resilver n’est pas une fonction du seul « To utilisés ». C’est une fonction de l’historique d’allocation, de la forme des workloads et de la contention.
Le postmortem a produit des actions simples et inconfortables : faire respecter de la marge de capacité, limiter le nombre de snapshots, et arrêter de construire des vdev larges pour des clusters VM sensibles à la latence.
Mini-récit 2 : L’optimisation qui a mal tourné
Un autre service a décidé que les resilvers prenaient trop de temps. Quelqu’un a trouvé des réglages en ligne et a configuré la concurrence scan/resilver agressivement sur toute la flotte.
En staging calme, c’était superbe : les rebuilds étaient plus rapides. Tout le monde s’est félicité. Le changement est passé en production.
Puis une vraie panne est arrivée en heures de pointe. Un disque est tombé. Le resilver a monté en puissance comme un réacteur : beaucoup d’I/O concurrente, minimal d’idle.
La vitesse de reconstruction s’est améliorée, certes. Pendant ce temps, la latence de la base de données est passée de « correcte » à « pourquoi tout timeoute ? ».
Le pire n’était pas la latence. C’étaient les retries. Les applis ont commencé à retenter les requêtes échouées, ce qui a augmenté la charge, augmenté l’I/O, augmenté la latence.
Le système est entré dans une spirale connue : plus il luttait, plus il s’échinait.
L’équipe a rollbacké les réglages en plein incident. Le rebuild a ralenti, mais la plateforme s’est stabilisée.
Conclusion du postmortem : « resilver plus rapide » n’est pas un défaut global. C’est un interrupteur en mode incident, lié aux heures business et aux SLO, avec monitoring et rollback explicites.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société de services financiers (oui, le genre qui aime le changement contrôlé) utilisait des vdev mirorés pour datasets critiques et RAIDZ pour les couches plus froides.
Ils appliquaient aussi une politique simple : les pools restent sous un seuil de remplissage défini, et la rétention des snapshots est plafonnée avec élagage régulier.
Un disque est tombé pendant la clôture trimestrielle. Bien sûr. L’on-call l’a remplacé, et le resilver a commencé. Ils n’ont pas touché aux réglages au départ.
Au lieu de ça, ils ont exécuté le runbook : mettre en pause les jobs batch non essentiels, vérifier qu’aucun scrub ne tourne, contrôler la vitesse de lien, consulter dmesg pour des resets, et surveiller les tableaux de latence.
Le resilver s’est terminé dans une fenêtre prévisible. Pas de drame. Pas de seconde défaillance. Pas de tuning héroïque.
La partie préférée de l’équipe : combien peu ils ont eu à expliquer à la direction—parce que rien de visible pour les clients ne s’est produit.
Le travail « ennuyeux » avait été fait des mois plus tôt : marge, design de vdev sensé et discipline opérationnelle.
C’est le type d’histoire de fiabilité que personne ne raconte aux conférences parce que ça ne se met pas sur un t-shirt. C’est pourtant celle que vous voulez.
Erreurs communes : symptôme → cause racine → fix
1) Symptom: Resilver rate starts decent, then collapses
Cause racine : Internal write stall du disque de remplacement (souvent SMR ou GC firmware), ou négociation de lien retombée, ou hit de régions plus fragmentées.
Fix : Vérifiez iostat -x pour l’augmentation de await et l’effondrement du MB/s ; vérifiez dmesg pour resets/vitesse de lien. Changez de port/câble/HBA ou remplacez le disque.
2) Symptom: “Scanned” grows fast, “issued” is tiny
Cause racine : Parcours riche en métadonnées avec faible reconstruction effective, souvent dû à la fragmentation et à de nombreux snapshots ; parfois dû aux réglages de throttling.
Fix : Réduisez le churn de métadonnées concurrent (pause des snapshot, activité lourde du filesystem). Envisagez temporairement de diminuer scan idle si le budget de latence le permet.
3) Symptom: Apps time out during resilver even though throughput isn’t high
Cause racine : Pic de latence de queue due à la contention I/O aléatoire ; quelques files saturées alors que le débit moyen semble modeste.
Fix : Surveillez await, profondeur de file et latence p99 applicative. Réduisez la charge, ou augmentez l’idle du resilver pour donner la priorité à la production.
4) Symptom: Resilver never finishes; progress inches and then “restarts”
Cause racine : Périphérique qui vacille, déconnexions transitoires, ou erreurs répétées forçant des retries ; parfois un backplane marginal.
Fix : Vérifiez les compteurs d’erreurs dans zpool status ; inspectez dmesg. Réparez le matériel. Aucun réglage ne compense un câble qui vous déteste.
5) Symptom: CPU pegged during resilver on an “I/O system”
Cause racine : Travail de checksum/chiffrement sur beaucoup de petits blocs, plus surcharge métadonnée. Peut être amplifié par dedup.
Fix : Confirmez avec top/vmstat et stats ARC ; réduisez le churn petits-blocs (pause migrations VM), et planifiez des upgrades CPU pour les pools chiffrés.
6) Symptom: Resilver is slow only on one pool, not others on the same hardware
Cause racine : Remplissage du pool, fragmentation, choix de taille de bloc dataset, nombre de snapshots, ou différences de largeur de vdev.
Fix : Comparez l’utilisation zfs list, le nombre de snapshots et les propriétés des datasets. Le matériel n’est pas « lent » ; votre historique d’allocation l’est.
7) Symptom: Rebuild speed improved after “tuning,” then pool gets weird later
Cause racine : Changements persistants de sysctl/réglages appliqués globalement sans garde-fous ; augmentation de pression I/O provoquant timeouts et défaillances secondaires.
Fix : Rendez les réglages limités à l’incident avec rollback explicite. Capturez les valeurs de base et remettez-les après que le pool soit sain.
Checklists / step-by-step plan
Step-by-step: when a disk fails and resilver begins
- Confirmer l’état :
zpool status. Assurez-vous que c’est un resilver, pas un scrub, et identifiez le vdev affecté. - Arrêter la maintenance concurrente : Si un scrub tourne, arrêtez-le sauf si la politique l’exige maintenant.
- Sanité matérielle : Confirmez le modèle du disque de remplacement (CMR vs SMR), la vitesse de lien, et l’absence de resets dans
dmesg. - Mesurer la contention :
iostat -xet tableaux de latence applicative. Décidez si vous avez la marge pour pousser le resilver plus fort. - Vérifier la pression mémoire :
vmstatet stats ARC. Assurez-vous qu’il n’y a pas de swap. - Décider la priorité : Si le risque est élevé (second disque instable, données critiques), priorisez le resilver. Si les heures business sont critiques, privilégiez les SLO.
- Appliquer les réglages prudemment (optionnel) : Augmentez l’agressivité du resilver par petites augmentations, en surveillant p95/p99.
- Communiquer : Fixez les attentes. « Dégradé jusqu’à X » est une déclaration de risque business, pas une curiosité stockage.
- Après achèvement : Vérifiez que le pool est sain, puis remettez les réglages temporaires. Planifiez un scrub après restauration de la redondance.
Checklist: safe speedups you can justify in a postmortem
- Mettre en pause les I/O batch non essentielles et les jobs générant beaucoup de snapshots.
- Arrêter les scrubs concurrents pendant le resilver (sauf contraintes de conformité).
- Réparer les problèmes de transport (resets de lien, vitesses SATA réduites) avant de tuner.
- Augmenter la concurrence du resilver modestement seulement si les disques ont de la marge et que la latence applicative est stable.
- Réduire temporairement le scan idling uniquement pendant une fenêtre d’incident contrôlée.
- Préférer les miroirs pour les couches où le risque de rebuild prime sur l’efficacité de capacité.
- Maintenir une marge de capacité comme politique, pas une suggestion.
Checklist: things you should not do during a resilver
- Ne pas activer dedup « pour économiser de l’espace » en plein incident.
- Ne lancez pas de grosses migrations, rebalancements ou réécritures massives à moins d’accepter un risque plus grand.
- Ne montez pas continuellement les réglages quand la latence est déjà mauvaise ; vous ne ferez qu’amplifier la défaillance.
- N’ignorez pas les logs kernel. Si vous voyez des resets ou des I/O errors, vous êtes en territoire matériel maintenant.
FAQ
1) Is resilver supposed to be faster than scrub?
Souvent, oui—parce que le resilver touche seulement les blocs alloués qui nécessitent reconstruction. Mais la fragmentation et le parcours des métadonnées peuvent effacer cet avantage.
Si le pool est ancien et riche en I/O aléatoire, le resilver peut ressembler à un scrub avec des étapes supplémentaires.
2) Why does “scanned” not match “resilvered”?
« Scanned » reflète combien le processus de scan a parcouru les pointeurs de blocs et les métadonnées du pool.
« Resilvered » est la donnée réellement reconstruite écrite sur le remplacement. Beaucoup de scan avec peu de resilvered signifie typiquement du travail métadonnées ou du throttling/IOPS limitant.
3) Does ZFS resilver copy only used space?
ZFS vise à resilver uniquement les blocs alloués (référencés), pas tout le périphérique brut. Voilà pourquoi l’espace libre ne coûte pas toujours du temps.
Mais les « blocs alloués » peuvent encore être dispersés en millions de petites étendues, ce qui rend l’opération lente.
4) Can I pause and resume a resilver?
Selon la plateforme et la version, vous pouvez parfois arrêter un scan et le reprendre plus tard, mais le comportement varie et peut redémarrer des portions de travail.
Opérationnellement : traitez « pause » comme « délai avec risque », pas comme un point de contrôle propre.
5) Should I run a scrub immediately after replacing a disk?
En général : resilver d’abord, scrub après. Tant que le pool est dégradé, vous voulez restaurer la redondance le plus vite possible.
Une fois le resilver terminé et le pool sain, un scrub est un bon suivi pour valider l’intégrité—planifiez-le en période de faible charge.
6) What’s the single safest way to shorten resilver time?
Réduire l’I/O concurrente et garder les pools moins pleins. Les réglages aident à la marge ; la charge et la fragmentation déterminent la base.
L’accélération « la plus sûre » est de diminuer la pression sur le pool afin que le resilver puisse utiliser les IOPS sans nuire à la production.
7) Are mirrors always better than RAIDZ for resilver?
Pas toujours, mais les miroirs resilvent généralement de façon plus prévisible et avec moins d’amplification de lecture de parité.
RAIDZ peut être efficace et fiable, mais le comportement de rebuild en cas de panne est plus complexe, surtout sur des vdev larges et des pools chargés.
8) Why did replacing a disk with a “same size” model make resilver slower?
Même capacité n’est pas même performance. Vous avez peut-être introduit un comportement SMR, des débits d’écriture soutenus plus faibles, un firmware moins bon sous écritures aléatoires, ou un lien négocié à une vitesse inférieure.
Vérifiez le modèle et inspectez les erreurs de transport.
9) Does compression make resilver faster or slower?
Généralement plus rapide pour les systèmes liés à l’I/O car moins d’octets transitent. Cela peut être plus lent si le CPU devient le goulot, surtout avec chiffrement et petits blocs.
Mesurez le CPU pendant le resilver ; ne supposez pas.
10) If resilver is slow, is my data at risk?
Un pool dégradé a une redondance réduite, donc le risque est plus élevé jusqu’à la fin du resilver. Un resilver lent prolonge la fenêtre d’exposition.
Voilà pourquoi la bonne réaction n’est pas seulement « attendre » ; c’est « réduire la charge, réparer les problèmes matériels et restaurer la redondance rapidement ».
Prochaines étapes que vous pouvez faire aujourd’hui
Si vous êtes au milieu d’un resilver douloureusement lent, faites ceci dans l’ordre :
- Exécutez
zpool statuset confirmez que vous ne scrubez pas accidentellement en étant dégradé. - Vérifiez
dmesgpour resets de lien et erreurs I/O ; réparez les problèmes physiques avant de toucher aux réglages ZFS. - Utilisez
iostat -xpour décider si vous êtes lié par les IOPS ou la bande passante. - Réduisez l’I/O concurrente : mettez en pause sauvegardes, migrations, jobs batch et tout churn de snapshots intensif.
- Si le budget de latence le permet, ajustez modestement l’agressivité du resilver et surveillez p95/p99 ; revenez en arrière après que le pool soit sain.
Si vous n’êtes pas actuellement dégradé, mieux encore. Profitez de ce calme pour acheter de la vitesse future : gardez de la marge, évitez les SMR surprises, choisissez la géométrie des vdev intentionnellement,
et traitez le temps de resilver comme une contrainte de conception prioritaire—pas un détail que vous découvrez quand le disque meurt.