La page est rouge. La latence augmente. Quelqu’un dit « lancez juste un scrub » comme si c’était une lingette magique.
Une autre personne répond « c’est déjà en resilver. » Vous avez maintenant deux adultes qui se disputent sur des verbes alors que votre
stockage essaie de ne pas se détruire.
Scrub et resilver ne sont pas des synonymes. Ils n’ont pas le même objectif, ils n’ont pas les mêmes déclencheurs,
et — ce qui est critique — ils n’ont pas le même profil de risque quand vous êtes déjà en train de boiter sur un vdev dégradé.
Les confondre, c’est transformer une défaillance disque récupérable en réunion « nous restaurerons depuis les sauvegardes ».
Le modèle mental : verification vs reconstruction
Pensez à un pool ZFS comme à deux travaux qui se déroulent dans le temps :
prouver que les données sont correctes et rétablir la redondance.
Scrub est le premier. Resilver est le second.
Un scrub est un audit d’intégrité complet. ZFS parcourt les blocs alloués, les lit, vérifie les checksums,
et si de la redondance existe (mirror, RAIDZ), il répare les copies défectueuses en réécrivant les bonnes données par-dessus les mauvaises.
Scrub concerne la cohérence de tout ce que vous avez stocké.
Un resilver est une reconstruction ciblée sur un périphérique qui doit redevenir un membre correct d’un vdev :
après un remplacement de disque, après un événement offline/online, après une déconnexion transitoire, après qu’un périphérique ait été retiré
puis réintroduit. Resilver concerne la restauration de la redondance pour ce périphérique (ou une portion de celui-ci), pas l’audit de l’univers.
Voici la phrase qui prévient les incidents : Scrub prouve vos données ; resilver reconstruit votre redondance.
Ils peuvent tous les deux découvrir des erreurs. Ils peuvent tous les deux réparer. Mais ils partent d’intentions différentes et couvrent des périmètres différents.
Définitions précises (et ce qu’elles ne sont pas)
Scrub : un audit piloté par les checksums des données allouées
Scrub lit les blocs alloués du pool. Pas l’espace libre. Pas « le disque brut ». Les données et métadonnées actives.
Le checksum de chaque bloc est vérifié. Si un bloc est corrompu, ZFS tente de récupérer une copie correcte depuis la redondance et de la réparer.
Si ZFS ne trouve pas de copie correcte, vous obtenez une erreur permanente : le checksum ne correspondait pas et il n’y avait pas de source saine.
Ce que scrub n’est pas :
- Ce n’est pas un scan de surface disque (c’est plutôt du diagnostic fournisseur ou des tests SMART longs).
- Ce n’est pas un « nettoyage de performance ». Si scrub vous a rendu plus rapide, vous étiez cassé.
- Ce n’est pas un remplacement des sauvegardes. Il peut détecter la corruption ; il ne peut pas faire apparaître des données manquantes.
Resilver : remettre un périphérique à son état correct
Resilver copie (ou reconstruit) les données nécessaires pour qu’un périphérique réintègre un vdev avec le contenu correct.
Dans un mirror, cela signifie copier les blocs du côté sain vers le disque nouveau/réintroduit.
Dans RAIDZ, cela signifie reconstruire à partir des parités pour remplir le disque nouveau/réintroduit.
Les implémentations modernes de ZFS font du resilver séquentiel et suivent des journaux de dirty time / checkpoints de resilver,
donc le resilver a tendance à se concentrer sur les données réellement allouées plutôt que « tout le disque ». C’est une bonne chose.
C’est aussi pourquoi certains minimisent la charge du resilver : c’est moins qu’une reconstruction complète du disque, mais c’est quand même un travail lourd,
sensible à la latence, combinant lectures et écritures.
Ce que resilver n’est pas :
- Ce n’est pas une vérification proactive d’intégrité. Il peut découvrir des erreurs, mais c’est collatéral, pas l’objectif.
- Ce n’est pas optionnel quand la redondance est compromise. Si vous êtes degraded, vous jouez au hasard à chaque lecture.
- Ce n’est pas « juste copier des fichiers ». C’est copier des blocs, y compris des métadonnées, souvent avec des accès assez aléatoires.
Une maxime que les opérationnels apprennent à la dure :
L’espoir n’est pas une stratégie.
— idée paraphrasée souvent citée dans les cercles SRE (associée communément à une citation de Gordon R. Sullivan)
Ce qui déclenche un scrub, ce qui déclenche un resilver
Si vous ne pouvez pas répondre à « pourquoi il scanne maintenant ? » vous ne maîtrisez pas votre système. ZFS fera ce que vous demandez,
et il fera aussi ce qu’il doit.
Déclencheurs de scrub
- Vous le lancez :
zpool scrub pool. - Votre planificateur le lance : cron, timer systemd, ou une interface NAS.
- Certaines appliances le lancent automatiquement après des mises à jour ou certains travaux de maintenance.
Scrub est une décision de politique. C’est de l’hygiène planifiée. Vous choisissez la fréquence en fonction du risque, de la charge et de la vitesse à laquelle vous voulez détecter les erreurs latentes.
Déclencheurs de resilver
- Remplacement de disque :
zpool replace. - Retour d’un périphérique : un câble ou HBA qui a fait un glitch et le disque revient.
- Online après offline :
zpool offlinepuiszpool onlineou un reboot. - Attach dans des mirrors :
zpool attachpour transformer un disque seul en mirror.
Resilver est un événement de disponibilité. Quelque chose a changé dans l’ensemble des périphériques qui forment la redondance, et ZFS répare le contrat de redondance.
Blague #1 : Un scrub, c’est comme faire l’inventaire ; un resilver, c’est comme réapprovisionner après qu’on ait volé une palette. Les confondre, c’est réorganiser des trombones pendant un incendie.
Ce qui est lu, ce qui est écrit, et pourquoi vos IOPS disparaissent
Profil I/O du scrub
Scrub lit chaque bloc alloué et le vérifie. Cela signifie :
- Les lectures dominent, souvent en streaming mais pas parfaitement séquentielles (les parcours de métadonnées sautent).
- Les écritures n’interviennent que lorsqu’une réparation est nécessaire (ou lors de la réécriture de métadonnées liée à détection/réparation).
- Des lectures aléatoires dans le pire des cas apparaissent sur des pools fragmentés ou des datasets très sollicités avec beaucoup de petits blocs.
Sur des pools sains, scrub est « principalement en lecture ». Sur des pools malsains, scrub peut devenir « lire tout, puis écrire des réparations », et c’est là que les plaintes de latence se font entendre.
Profil I/O du resilver
Resilver est par définition lecture + écriture : il doit peupler un périphérique avec les bonnes données. Selon la topologie :
- Resilver en mirror : lire depuis le(s) disque(s) sain(s), écrire sur le disque nouveau/revenu.
- Resilver en RAIDZ : lire depuis tous les disques restants (pour reconstruire), écrire sur le disque cible.
- Vdevs spéciaux (métadonnées/petits blocs) peuvent rendre le resilver étonnamment « en pointes ».
Resilver concurrence votre workload de production pour les IOPS et la bande passante. Si le pool est degraded, resilver concurrence aussi « chaque lecture normale a maintenant moins de redondance », ce qui augmente le coût du traitement des erreurs.
Implication opérationnelle
Scrub, c’est une douleur planifiée ; resilver, c’est une douleur non planifiée. Planifiez le premier pour que le second ne devienne pas une catastrophe.
Si vous êtes en train de resilver, faites des réglages de performance en second plan par rapport à la sécurité des données. Votre travail est de terminer le resilver sans perdre un autre disque.
Comment lire zpool status comme vous le pensez
zpool status est l’endroit où la réalité vit. Il vous dit si vous êtes en train de scrub ou de resilver, à quel point vous en êtes,
et si des erreurs sont trouvées ou réparées.
Champs clés qui comptent en incident
- state : ONLINE / DEGRADED / FAULTED / UNAVAIL. Cela détermine votre urgence.
- scan : scrub in progress, resilver in progress, scrub repaired X, resilvered X, et un débit/ETA.
- errors : « No known data errors » n’est pas un tour de piste triomphal, mais c’est un bon signe.
- colonnes READ/WRITE/CKSUM par périphérique : elles vous disent si le périphérique ment, échoue ou est éjecté.
Si vous ne retenez qu’une chose : la ligne “scan” indique quel processus est en cours. Arrêtez de deviner.
Tâches pratiques : commandes, sorties, décisions (12+)
Voici ce que vous faites réellement à 02:13 quand quelqu’un demande « c’est sûr ? » Chaque tâche inclut :
la commande, ce que signifie la sortie, et la décision qu’elle doit entraîner.
Task 1: Confirmer si c’est un scrub ou un resilver
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
scan: resilver in progress since Thu Dec 26 00:41:11 2025
1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
742G resilvered, 13.40% done, 03:46:12 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
sdw 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
errors: No known data errors
Sens : C’est un resilver, pas un scrub (« scan: resilver in progress »). Le pool est DEGRADED mais pas en échec.
Décision : Ne lancez pas un scrub « pour aider ». Laissez le resilver se terminer à moins que vous n’ayez des preuves de corruptions silencieuses à auditer immédiatement (rare pendant un resilver actif).
Task 2: Lancer un scrub volontairement (et seulement volontairement)
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 01:12:03 2025
388G scanned at 1.05G/s, 122G issued at 331M/s, 5.41T total
0B repaired, 2.20% done, 04:41:09 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Sens : Scrub est en cours ; « 0B repaired » est bon jusqu’ici. Le taux « issued » montre l’I/O réel envoyé, parfois inférieur à « scanned ».
Décision : Laissez-le tourner si la charge le tolère. Si la production souffre, bridez via les paramètres (selon la plateforme) ou lancez hors heures ouvrées la prochaine fois.
Task 3: Arrêter un scrub (parce que vous aimez votre latence)
cr0x@server:~$ sudo zpool scrub -s tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub canceled on Thu Dec 26 01:24:55 2025
512G scanned at 1.02G/s, 0B repaired, 9.24% done
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Sens : Scrub arrêté. Vous n’avez pas « cassé » le pool ; vous avez juste annulé l’audit.
Décision : Replanifiez le scrub pour une fenêtre où il ne concurrencera pas l’I/O de pointe. Ne passez pas six mois sans scrub parce que l’annulation vous a fait plaisir.
Task 4: Identifier quel périphérique est en resilver (et pourquoi)
cr0x@server:~$ sudo zpool status -P tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
scan: resilver in progress since Thu Dec 26 00:41:11 2025
742G resilvered, 13.40% done, 03:46:12 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_A1A... ONLINE 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_B2B... ONLINE 0 0 0 (resilvering)
Sens : Le tag « (resilvering) » vous indique la cible. -P affiche les chemins persistants, pas les noms fragiles /dev/sdX.
Décision : Vérifiez que le disque physique correspond au chemin by-id avant de retirer quoi que ce soit d’un châssis. Cela évite les catastrophes de « mauvais disque remplacé ».
Task 5: Remplacer un disque défaillant correctement
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80EFAX_B2B... /dev/disk/by-id/ata-WDC_WD80EFAX_NEW...
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Thu Dec 26 02:03:22 2025
96.4G scanned at 485M/s, 62.1G issued at 313M/s, 5.41T total
62.1G resilvered, 1.15% done, 05:02:10 to go
Sens : Remplacement initié ; le resilver démarre. « Issued » montre le travail réel de reconstruction.
Décision : Si le débit de resilver est extrêmement faible, passez immédiatement au diagnostic du goulot (voir la feuille de route). Les resilvers lents prolongent la fenêtre de risque.
Task 6: Repérer la corruption silencieuse vs erreurs de périphérique
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 2
sdb ONLINE 0 0 0
errors: No known data errors
Sens : Le périphérique sda a des erreurs de checksum. Le scrub n’a rien réparé, mais ZFS a observé de mauvaises données sur ce périphérique et les a corrigées depuis la redondance.
Décision : Investiguer sda immédiatement : câblage/HBA, firmware, SMART, et envisager un remplacement préventif. Les erreurs de checksum sont ZFS qui vous dit poliment qu’un disque a menti.
Task 7: Corréler les erreurs ZFS avec les logs noyau
cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Sense Key : Medium Error [current]
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Add. Sense: Unrecovered read error
[Thu Dec 26 03:11:19 2025] blk_update_request: I/O error, dev sda, sector 2384812048
[Thu Dec 26 03:11:21 2025] ata3: hard resetting link
Sens : Ce n’est pas « ZFS qui fait l’exigeant ». Le noyau rapporte de vraies erreurs de lecture et des réinitialisations de lien.
Décision : Traitez cela comme un disque ou un chemin en train d’échouer. Si vous voyez des réinitialisations, suspectez aussi le câblage SATA/SAS, l’expander ou l’HBA — pas seulement le disque.
Task 8: Vérifier SMART rapidement (triage)
cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 098 098 010 Pre-fail Always - 12
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 4
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 4
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 87
Sens : « PASSED » n’est pas une exonération. Les secteurs pending/uncorrectable sont mauvais ; des CRC élevés crient « problème de câblage/chemin ».
Décision : Si les CRC augmentent, corrigez le câblage/backplane/HBA en priorité. Si des pending/uncorrectable existent, planifiez un remplacement même si le disque « fonctionne » encore.
Task 9: Trouver ashift et la topologie du pool (mettre les attentes)
cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|vdev_tree|type'
ashift: 12
type: 'root'
type: 'mirror'
type: 'disk'
type: 'disk'
Sens : ashift: 12 implique des secteurs 4K. Un mauvais choix d’ashift peut punir l’I/O aléatoire et rendre les scrubs/resilvers plus lents qu’ils ne devraient.
Décision : Si ashift est erroné (trop petit), vous ne pouvez pas le corriger sur place. Vous planifiez une migration, pas des exploits pendant un incident.
Task 10: Vérifier si autotrim affecte la performance du scan
cr0x@server:~$ sudo zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim on local
Sens : Autotrim peut ajouter du travail de fond sur les pools SSD. Généralement sans problème, parfois contributeur à « pourquoi tout est lent maintenant ? ».
Décision : Si vous resilver sur des SSD sous forte charge, envisagez de désactiver temporairement le churn de fond non essentiel — mais seulement si vous comprenez le comportement et l’endurance de vos SSD.
Task 11: Observer l’I/O en temps réel pendant scrub/resilver
cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.1 0.0 2.8 18.6 0.0 75.5
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 415.2 18.1 54032 6120 252.1 9.84 23.5 22.9 37.2 1.9 82.4
sdb 402.7 17.5 52810 5904 251.6 9.21 22.1 21.6 35.8 1.8 79.3
Sens : Un %util élevé et une file d’attente (avgqu-sz) avec await en hausse indiquent des disques saturés. Cela va allonger votre scan et frapper la latence applicative.
Décision : Si les SLOs de production comptent, bridez le scan ou déplacez la charge. Si le resilver est prioritaire, acceptez la douleur mais surveillez l’apparition d’un second disque qui montre des erreurs.
Task 12: Identifier si la pression ARC aggrave tout
cr0x@server:~$ sudo arcstat 2 3
time read miss miss% dmis dm% pmis pm% mmis mm% size c avail
01:33:20 328K 112K 34 28K 25 72K 64 12K 11 92G 104G 18G
01:33:22 341K 126K 36 31K 25 83K 66 12K 10 92G 104G 18G
01:33:24 355K 149K 42 45K 30 96K 64 8K 5 92G 104G 18G
Sens : Une hausse du taux de miss pendant le scan suggère que le scan évince des caches utiles, surtout sur des systèmes chargés.
Décision : Si les scans détruisent régulièrement le cache et nuisent aux applications, planifiez-les mieux, ou ajustez le comportement du scan (selon la plateforme), ou ajoutez de la RAM si la charge le justifie.
Task 13: Vérifier la dernière fois où un scrub a été fait et si vous êtes en retard
cr0x@server:~$ sudo zpool status tank | grep -E 'scan:|scrub'
scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025
Sens : Vous avez une base : durée et résultat.
Décision : Si vous ne trouvez pas une ligne récente « scrub repaired … with … errors » dans votre historique, vous naviguez à l’aveugle. Mettez en place un calendrier et des alertes.
Task 14: Vérifier si un resilver redémarre ou ne progresse pas
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
pool: tank
state: DEGRADED
scan: resilver in progress since Thu Dec 26 00:41:11 2025
1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
742G resilvered, 13.40% done, 03:46:12 to go
Sens : « Scanned » augmente tandis que « issued » stagne peut indiquer que le scan parcourt les métadonnées sans émettre d’I/O utile — parfois à cause de contention, parfois à cause d’erreurs.
Décision : Si le pourcentage ne bouge pas après plusieurs contrôles, cherchez des erreurs de périphérique et des goulots. N’attendez pas en espérant que ça s’arrange.
Task 15: Confirmer la santé du pool après la fin
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: resilvered 5.41T in 06:02:18 with 0 errors on Thu Dec 26 06:43:29 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Sens : Resilver terminé sans erreurs et pool ONLINE.
Décision : Maintenant vous lancez un scrub (bientôt) si vous n’en avez pas fait récemment, car la fin d’un resilver ne garantit pas qu’il n’y a pas de corruptions latentes ailleurs.
Feuille de diagnostic rapide (trouver le goulot vite)
Quand un scrub/resilver est lent, les équipes perdent des heures à se chamailler sur « l’overhead ZFS ». Ne le faites pas.
Trouvez le goulot. C’est presque toujours l’un des suivants : périphérique, contrôleur/chemin, contention workload,
recordsize/petits blocs, ou pression mémoire système.
Première étape : établir ce qui tourne et ce que signifie « lent »
-
Vérifier le type de scan et la progression :
lancezzpool status. Notez scanned/issued rate, ETA, et si des erreurs apparaissent.
Si l’ETA augmente, ce n’est pas juste lent ; c’est instable. -
Vérifier l’état du pool :
ONLINE vs DEGRADED change tout. Si DEGRADED, finir le resilver est la priorité numéro un.
Deuxième étape : trouver la couche limitante (disque vs chemin vs CPU vs cache)
-
Saturation des disques :
iostat -x. Cherchez un%utilélevé, unawaitélevé, de longues files d’attente.
Si un disque a une latence bien pire que ses pairs, c’est le coupable. -
Erreurs noyau :
dmesg -T. Réinitialisations de lien, timeouts, « Medium Error », « I/O error » sont des preuves solides.
Corrigez d’abord les problèmes de chemin avant de tuner ZFS. -
Pression ARC :
arcstatou équivalent.
Si le scan évince les données chaudes, les applications souffrent et peuvent amplifier l’I/O. -
Goulots CPU (moins fréquents mais réels sur des charges à checksum intensif) :
vérifiez l’utilisation CPU système, et si compression/chiffrement est actif. Scrub vérifie des checksums ; cela coûte du CPU.
Troisième étape : décider du mode d’opération
-
Mode sécurité d’abord (degraded, erreurs disque récentes, matériel incertain) :
minimisez le churn supplémentaire, ne lancez pas de nouveaux scrubs, réduisez les pics d’écriture applicatifs, et évitez les reboots. -
Mode performance d’abord (pool sain, scrub planifié) :
planifiez, bridage, et gardez une situation prévisible. L’objectif est « finir sans que personne ne remarque », pas « battre des records ».
Erreurs courantes : symptômes → cause racine → correction
Erreur 1 : « Scrub va reconstruire le disque manquant »
Symptômes : Le pool est DEGRADED. Quelqu’un lance scrub. Rien n’est « réparé ». L’état dégradé persiste.
Cause racine : Scrub n’est pas une opération de reconstruction de redondance. Il audite et répare les blocs corrompus ; il ne repopule pas un périphérique absent/échoué.
Correction : Remplacez/remettez online/attachez le périphérique pour déclencher le resilver. Utilisez zpool replace ou zpool online selon le cas. Puis surveillez le resilver.
Erreur 2 : « Resilver terminé, donc les données sont vérifiées »
Symptômes : Après remplacement disque, l’équipe se détend. Des semaines plus tard, une lecture échoue avec erreurs de checksum ou une app signale de la corruption.
Cause racine : Resilver reconstruit la redondance vers un périphérique ; il ne parcourt pas nécessairement chaque bloc du pool.
Correction : Planifiez des scrubs réguliers. Après des événements majeurs (pannes de disque, resets de contrôleur), lancez un scrub dans la prochaine fenêtre sûre.
Erreur 3 : Annuler les scrubs pour toujours parce qu’« ils font mal »
Symptômes : Les scrubs sont toujours annulés. Finalement un second disque lâche pendant une reconstruction et des erreurs latentes apparaissent au pire moment.
Cause racine : Scrub est le mécanisme qui trouve les erreurs sectorielles latentes tant que vous avez encore de la redondance pour les réparer.
Correction : Lancez des scrubs selon une cadence prévisible. Si l’impact est inacceptable, ajustez l’horaire, ajoutez de la marge I/O, ou repensez la conception du pool.
Erreur 4 : Prendre les erreurs de checksum pour du « ZFS dramatique »
Symptômes : Les compteurs CKSUM augmentent sur un périphérique. Le pool reste ONLINE. Les gens ignorent.
Cause racine : Les erreurs de checksum signifient que les données lues depuis ce périphérique ne correspondaient pas à ce que ZFS attendait. ZFS a corrigé cette fois-ci en utilisant la redondance.
Correction : Vérifiez le câblage/HBA, puis SMART, puis remplacez le périphérique si les erreurs persistent. Lancez aussi un scrub pour forcer vérification et guérison.
Erreur 5 : Optimiser la vitesse des scans en affamant les applications (ou l’inverse)
Symptômes : Vous bridez tellement les scrubs qu’ils durent des jours, ou vous les débridez tellement que la production s’écroule.
Cause racine : Les scans sont des I/O de fond qui doivent être équilibrés face aux exigences de latence de premier plan.
Correction : Choisissez une politique explicite : fenêtres horaires, bridages, et alertes si un scan dépasse une durée seuil (signe d’un problème matériel sous-jacent).
Erreur 6 : Remplacer le mauvais disque parce que /dev/sdX a changé
Symptômes : Après un reboot, le nom du disque « défaillant » change. Le technicien retire le mauvais chariot. Vous êtes maintenant dégradé deux fois.
Cause racine : Utiliser des nœuds de périphériques éphémères au lieu d’identifiants stables.
Correction : Utilisez les chemins /dev/disk/by-id dans ZFS et la documentation opérationnelle. Vérifiez avec zpool status -P avant toute action physique.
Trois mini-histoires d’entreprise (comment ça tourne mal)
Mini-histoire #1 : L’incident causé par une mauvaise hypothèse
Une entreprise SaaS de taille moyenne utilisait ZFS sur une paire de HDD en mirror par nœud. Rien d’extraordinaire. Un disque est tombé sur un nœud pendant un week-end calme.
L’ingénieur d’astreinte a vu « DEGRADED » et a fait ce qu’il pensait être sûr et conservateur : il a lancé un scrub.
L’hypothèse était simple : scrub = « réparation ». Et ZFS répare pendant un scrub — quand il a de la redondance. Mais le disque manquant l’était toujours.
Scrub a parcouru le disque restant, vérifié ce qu’il pouvait, et a forcé beaucoup de lectures. Entre-temps, le pool n’avait plus de redondance.
Le disque restant n’a pas apprécié d’être la seule source de vérité sous une charge soutenue. Des secteurs latents sont apparus.
Quelques blocs n’ont pas pu être lus proprement. Sans partenaire miroir, ZFS n’a pas pu les guérir. Le pool avait maintenant de vraies erreurs de données, pas juste une « redondance dégradée ».
Ils ont remplacé le disque lundi matin et ont resilveré. La redondance est revenue, mais les blocs endommagés sont restés endommagés — car la seule copie correcte n’avait jamais existé.
Le fallout n’était pas une perte totale, mais pire : une poignée d’objets corrompus dans le blob store de l’app, découverts par des clients en production.
Le postmortem a été ennuyeux : traiter « degraded » comme « minimiser le stress supplémentaire », prioriser la restauration de la redondance (resilver), et lancer un scrub après resilver dans une fenêtre.
Aussi : mettre « scrub is not a rebuild » en grandes lettres dans le runbook.
Mini-histoire #2 : L’optimisation qui a mal tourné
Une société financière avait des pools RAIDZ2 soutenant un entrepôt de données. Les scrubs étaient pénibles, alors un ingénieur a « optimisé » en lançant des scrubs constamment à faible intensité
et en les annulant pendant les heures ouvrées. L’idée était de toujours progresser tout en restant invisible.
En pratique, les scrubs ne finissaient jamais. Ils tournaient quelques heures, étaient annulés, redémarraient plus tard, étaient annulés à nouveau. Des semaines passaient sans scrub complet.
Tout le monde était rassuré parce que l’historique montrait « scrub started » souvent. La direction aime l’activité.
Puis un disque est tombé. Le resilver a démarré, et il a été plus lent que prévu parce qu’un des disques restants avait un nombre croissant de secteurs illisibles.
Les secteurs illisibles existaient depuis un certain temps, mais le schéma de scrubs jamais achevés n’avait jamais forcé un passage complet qui aurait mis le problème en lumière plus tôt.
Le resilver a rencontré ces mauvais secteurs au pire moment : alors que la redondance était réduite et la charge élevée.
Le resilver s’est traîné, ce qui a maintenu le pool dans une fenêtre de risque plus longue, et la performance de l’entrepôt s’est effondrée pendant les rapports de pointe.
La correction n’a pas été « scrub moins ». Ce fut « scrub correctement » : planifier une fenêtre où il se complète, alerter sur la fin et les erreurs, et suivre les durées de référence.
Leur « optimisation » était de l’activité sans résultats, la version corporate de courir sur place.
Mini-histoire #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société média exploitait de grands pools ZFS avec des mirrors SSD pour contenu chaud et du RAIDZ pour archives tièdes.
Rien d’héroïque, mais ils faisaient trois choses disciplinées : scrubs mensuels avec alertes de fin, noms de périphériques by-id stables partout,
et une règle stricte que toute erreur de checksum déclenche une investigation sous 24 heures.
Un matin, les alertes ont montré qu’un scrub s’était terminé mais avait enregistré un petit nombre d’erreurs de checksum sur un SSD.
Le pool est resté ONLINE. Aucun impact client. C’est le moment exact où les équipes sont tentées de hausser les épaules.
Ils n’ont pas haussé les épaules. Ils ont sorti SMART, vu les CRC monter, et trouvé un câble marginal dans le backplane.
Ils ont réparé le chemin, remplacé le câble et remonté, puis lancé un scrub de contrôle.
Plus d’erreurs. Problème terminé tranquillement.
Un mois plus tard, un autre nœud a perdu un disque pour de vrai. Resilver s’est terminé rapidement parce que les périphériques restants étaient sains
et l’équipe avait déjà confiance dans leurs baselines de scan. Pas de drame, pas de « peut-être que ça va », pas de fichiers corrompus surprises.
Les pratiques ennuyeuses sont sous-estimées parce qu’elles ne produisent pas d’adrénaline. Elles produisent de l’uptime.
Faits intéressants et contexte historique
- ZFS a été conçu autour du checksumming de bout en bout, ce qui signifie que c’est le système de fichiers, pas le disque, qui décide si les données sont correctes.
- Scrub existe pour détecter les erreurs latentes — la classe « bit rot » que le RAID traditionnel peut ne pas détecter avant qu’il ne soit trop tard.
- Les premiers systèmes ZFS ont popularisé les scrubs réguliers comme habitude opérationnelle, similaire à la popularisation des sauvegardes et des contrôles de cohérence en base de données.
- Le comportement du resilver a évolué ; les anciennes approches pouvaient ressembler à « reconstruire tout le disque », tandis que les approches récentes ciblent l’espace alloué et sont plus séquentielles quand c’est possible.
- Le resilver RAIDZ lit intrinsèquement de nombreux disques pour reconstruire le disque manquant. Les mirrors peuvent être plus doux : lire un côté, écrire l’autre.
- Le nommage des périphériques a causé des dégâts opérationnels ; le passage vers des identifiants stables (
by-id, WWN) a été motivé par de vrais incidents de remplacement du mauvais disque. - Les checksums ne préviennent pas la corruption ; ils la détectent. La prévention vient de la redondance plus les actions de réparation (scrub ou lectures normales qui provoquent healing).
- Scrub n’est pas une vérification de l’espace libre. Si vous voulez stresser un disque neuf, faites un burn-in et des tests SMART, pas seulement un scrub ZFS.
- Les workloads sensibles à la latence remarquent les scans en premier ; la douleur n’est pas la « bande passante », c’est le délai d’attente en file. C’est pourquoi iostat
awaitimporte plus que les MB/s bruts.
Blague #2 : Les scrubs sont la visite chez le dentiste du stockage — vous les sautez assez longtemps et vous finirez par payer des canaux radiculaires.
Listes de contrôle / plans étape par étape
Plan A : Vous avez remplacé un disque et un resilver a démarré
- Confirmer le périphérique cible :
zpool status -P. Assurez-vous que vous resilverisez ce que vous pensez resilveriser. - Vérifier l’état du pool : si DEGRADED, traitez cela comme un incident prioritaire jusqu’à la fin du resilver.
- Surveiller les nouvelles erreurs : vérifiez les compteurs
READ/WRITE/CKSUMtoutes les 10–30 minutes pendant les premières heures. - Vérifier les logs noyau : si vous voyez des resets/timeouts, corrigez le chemin maintenant. Un lien instable peut étirer le resilver et provoquer d’autres pannes.
- Décider de la politique de contention : si c’est une charge critique, vous pouvez réduire temporairement la charge applicative pour finir le resilver plus vite.
- Après la fin : vérifiez ONLINE et 0 erreurs ; puis planifiez un scrub bientôt (pas forcément immédiatement) pour valider le pool plus largement.
Plan B : Un scrub est lent et le business crie
- Mesurer l’impact : vérifiez la latence applicative et le
awaitdisque. Si vous ne pouvez pas le quantifier, vous négociez sur des impressions. - Vérifier si le scrub trouve des réparations :
zpool status. S’il répare, l’arrêter peut reporter la guérison. Équilibrez le risque. - Décider : annuler ou continuer : Si la production est en jeu et que le pool est sain, annulez le scrub et replanifiez. Si le pool montre des erreurs, penchez vers continuer dans une fenêtre contrôlée.
- Corriger la cause racine : les scrubs lents pointent souvent vers des disques qui faiblissent, des problèmes de câblage, ou une conception de pool sans marge IOPS.
- Baseliner les durées : enregistrez combien de temps prennent les scrubs sur un matériel sain. Quand c’est le double, quelque chose a changé.
Plan C : Vous voyez des erreurs de checksum mais tout « a l’air ok »
- Identifier le périphérique : quel disque accumule les erreurs
CKSUM? - Vérifier dmesg : cherchez des erreurs I/O et des réinitialisations.
- Vérifier SMART : les pending sectors et CRC indiquent si c’est média ou chemin.
- Lancer un scrub (dans une fenêtre sûre) : forcer la vérification et la guérison.
- Remplacer ou réparer le chemin : si les erreurs persistent, ne négociez pas avec un disque qui ment. Remplacez-le.
FAQ
1) Un scrub lit-il l’espace libre ?
Non. Scrub parcourt les blocs alloués (données actives et métadonnées). C’est une vérification d’intégrité, pas un scan de surface disque.
2) Un resilver vérifie-t-il les checksums comme le scrub ?
Les opérations de resilver impliquent la lecture de blocs et l’écriture de copies reconstruites/correctes, et la vérification des checksums se produit lors des lectures normales.
Mais resilver n’est pas un audit exhaustif de tout le pool ; il se concentre sur ce dont le périphérique cible a besoin pour réintégrer correctement.
3) Dois-je lancer un scrub immédiatement après un resilver ?
En général : bientôt, oui. Immédiatement : ça dépend. Si le système est fragile ou fortement chargé, planifiez-le pour la prochaine fenêtre sûre.
L’essentiel est de valider le pool dans son ensemble après un événement perturbateur.
4) Pourquoi « scanned » est supérieur à « issued » dans zpool status ?
« Scanned » reflète jusqu’où ZFS a parcouru l’espace qu’il doit considérer. « Issued » reflète les requêtes I/O effectivement envoyées.
L’écart peut s’élargir à cause du parcours de métadonnées, du saut de régions non nécessaires, de la contention ou de détails d’implémentation.
5) Est-il sûr d’annuler un resilver ?
« Sûr » est la mauvaise question. Annuler un resilver vous maintient dégradé plus longtemps. Cela augmente le risque.
Vous n’annulez que si nécessaire, et vous le relancez dès que possible après avoir réglé la raison (comme un problème de chemin).
6) Scrub a trouvé des erreurs mais « errors: No known data errors » apparaît toujours. Pourquoi ?
ZFS peut corriger certaines erreurs en utilisant la redondance. S’il a tout réparé avec succès, il peut ne plus y avoir d’erreurs de données connues.
La présence de compteurs CKSUM sur un périphérique reste importante : quelque chose a renvoyé de mauvaises données.
7) Lancer des scrubs réduit-il la durée de vie des SSD ?
Scrub est majoritairement en lecture ; les écritures interviennent lors des réparations. Les lectures consomment quand même des ressources des SSD (travail contrôleur), mais l’impact sur l’endurance est généralement modéré.
Le vrai problème est l’impact sur la performance et s’assurer que vos SSD sont sains et correctement refroidis.
8) À quelle fréquence dois-je lancer un scrub ?
Pratique courante : mensuellement pour de grands pools, plus souvent pour les systèmes critiques, moins souvent pour des archives peu utilisées — si vous avez un bon monitoring et connaissez votre risque.
La bonne réponse : assez fréquemment pour détecter les erreurs latentes avant qu’une seconde panne les rende irrécupérables.
9) Pourquoi le resilver prend-il si longtemps en RAIDZ comparé aux mirrors ?
Le resilver RAIDZ nécessite de lire données/parité depuis plusieurs disques pour reconstruire ce qui appartient au disque manquant. Les mirrors peuvent copier depuis un seul membre sain.
La topologie dicte le fan-out I/O et la pénalité en cas de contention.
10) Si mon pool est sain, puis-je ignorer des erreurs de checksum occasionnelles ?
Non. Occasionnel peut signifier « rare et transitoire », mais cela peut aussi être un signal précoce. Investiguer d’abord.
Le coût de vérifier les logs et SMART est peu élevé comparé à la découverte du problème au moment d’un événement dégradé.
Prochaines étapes que vous pouvez faire cette semaine
- Planifiez le scrub sur une cadence qui se complète réellement (et alertez à la fin et en cas d’erreurs). « Démarré » n’est pas un statut utile.
- Mesurez la durée des scrubs sur un matériel sain. Quand cela change sensiblement, enquêtez avant d’avoir une panne.
- Standardisez les identifiants de disque stables (
/dev/disk/by-id) dans les configs de pool et les runbooks. - Rédigez une procédure d’une page pour pool dégradé : prioriser le resilver, minimiser le churn, surveiller le second disque, éviter les reboots risqués.
- Formez l’équipe sur
zpool status: la ligne scan, les compteurs d’erreur, et ce que « No known data errors » promet ou non. - Décidez votre politique pour l’impact des scans : quand annuler un scrub, quand le laisser tourner, et comment gérer la pression de la production sans abandonner les vérifications d’intégrité.
Scrub et resilver sont tous deux des opérations « scan », d’où la tendance à les confondre dans la conversation.
Mais en exploitation, les verbes comptent. L’un prouve. L’autre reconstruit. Si vous les traitez comme interchangeables, ZFS n’argumentera pas avec vous — il exécutera simplement votre erreur.