Scrub ZFS lent : distinguer la lenteur normale d’un vrai problème

octobre 31, 2025 • février 3, 2026 • Lecture : 30 min • Views: 7

Cet article vous a aidé ?

Votre scrub est « en cours » depuis suffisamment longtemps pour que les gens se demandent si le stockage est hanté. Les applications semblent lentes, les tableaux de bord affichent une mer d’I/O, et l’ETA est soit absent soit mensonger. Il faut savoir : est-ce un scrub normal et ennuyeux qui fait son travail, ou est-ce le symptôme de quelque chose qui va vous mordre plus tard ?

Ceci est la méthode adaptée à la production pour répondre à cette question. Nous allons séparer la lenteur attendue (celle que vous planifiez et tolérez) de la lenteur pathologique (celle que vous corrigez avant qu’elle ne devienne un incendie de tickets de support).

Ce que fait réellement un scrub (et pourquoi « lent » est parfois correct)

Un scrub ZFS n’est pas un benchmark ni une opération de copie. C’est une patrouille d’intégrité des données. ZFS parcourt les blocs alloués du pool, les lit, vérifie les checksums et — si la redondance le permet — répare les corruptions silencieuses en réécrivant les bonnes données sur les mauvaises. C’est de la maintenance proactive, du type « trouver le problème avant que l’utilisateur ne le fasse ».

Cela implique deux choses qui surprennent :

Les scrubs sont fondamentalement orientés lecture (avec des écritures occasionnelles lors des réparations). Votre pool peut être « lent » parce que les lectures sont lentes, parce qu’il y a de la contention avec des workloads réels, ou parce que ZFS choisit volontairement d’être poli.
Les scrubs opèrent au niveau bloc, pas fichier. La fragmentation, le choix de recordsize et le surcoût métadonnées peuvent peser davantage que le débit brut disque en MB/s.

Les scrubs se comportent aussi différemment selon la topologie des vdevs. Les mirrors ont tendance à scrubber plus vite et de façon plus prévisible que les RAIDZ, car les mirrors peuvent servir les lectures depuis l’un ou l’autre côté et ont des calculs de parité plus simples. Les scrubs RAIDZ sont parfaitement valides quand le pool est sain, mais ils peuvent devenir une longue promenade si vous avez des vdevs larges, des disques marginaux ou une I/O aléatoire lourde générée par les applications.

Voici la règle de production que j’utilise : le temps de scrub est une propriété observable de votre système, pas une faute morale. Mais un débit de scrub qui s’effondre, ou un ETA qui augmente, est un signal. Pas toujours un incendie, mais toujours digne d’un examen.

Blague courte #1 : Un scrub sans ETA, c’est comme une panne de stockage sans postmortem — techniquement possible, socialement inacceptable.

Faits intéressants et un peu d’histoire

ZFS a popularisé les checksums de bout en bout dans le stockage serveur grand public. Les checksums sont stockés séparément des données, ce qui permet à ZFS de détecter les « disques menteurs » qui renvoient des blocs corrompus sans erreurs d’I/O.
Le scrub est la réponse de ZFS au « bit rot » — la corruption silencieuse et incrémentale que les RAID traditionnels détectent rarement sauf si une lecture déclenche une reconstruction de parité.
Le terme « scrub » vient de systèmes de stockage plus anciens qui scannaient périodiquement les médias pour des erreurs. ZFS l’a rendu routinier et visible par l’utilisateur.
RAIDZ a été conçu pour éviter le write hole observé dans les implémentations RAID5/6 classiques, en gardant des métadonnées transactionnelles cohérentes et une sémantique copy-on-write.
ZFS est né chez Sun Microsystems puis s’est largement diffusé via OpenZFS. Le comportement moderne de ZFS dépend de la version d’OpenZFS, pas seulement de la marque « ZFS ».
Avant, les scrubs étaient plus douloureux sur des systèmes sans bon ordonnancement I/O ou où le throttling de scrub était primitif. Les piles Linux et FreeBSD modernes offrent plus de leviers, mais aussi plus de façons de se tirer une balle dans le pied.
Les métadonnées comptent. Les pools avec des millions de petits fichiers peuvent scrubber plus lentement qu’un pool avec moins de gros fichiers, même si l’« espace utilisé » paraît similaire.
Les disques SMR rendent les scrubs plus imprévisibles dans la pratique. Quand le disque effectue sa collecte de déchets shingled en arrière-plan, une « lecture » peut devenir une « lecture plus réécriture interne dramatique ».
Les baies entreprise effectuent des patrol reads depuis des décennies, souvent de façon invisible. ZFS vous donne simplement la vérité au grand jour — et il se trouve que la vérité peut être lente.

Lenteur de scrub normale vs véritable problème : modèle mental

« Scrub lent » est ambigu. Il faut préciser de quel type de lenteur il s’agit. Je le divise en quatre catégories :

1) Lenteur « grand pool, physique normal »

Si vous avez des centaines de To et des disques tournants, un scrub qui prend des jours peut être normal. Il est limité par la bande passante de lecture séquentielle, la topologie des vdevs, et le fait que les scrubs n’ont pas toujours des accès parfaitement séquentiels (les blocs alloués ne sont pas forcément contigus).

Signes que c’est normal :

Le taux de scrub est stable sur des heures.
La latence disque n’explose pas.
L’impact sur les applications est prévisible et borné.
Pas d’erreurs de checksum, pas d’erreurs de lecture.

2) Lenteur « volontairement bridée »

ZFS se limite souvent lors des scrubs pour que les workloads de production ne s’effondrent pas. Cela signifie que votre scrub peut sembler décevant de lenteur tandis que le système reste utilisable. C’est un comportement d’ingénierie souhaitable. Vous pouvez le régler, mais faites-le délibérément.

Signes que c’est du throttling :

Le CPU est globalement tranquille.
Les IOPS ne sont pas saturés, mais la progression du scrub est lente.
La latence des workloads reste dans les SLO.

3) Lenteur « contention par les workloads »

Si le pool sert une base de données occupée, une ferme de VM ou un workload objet, les lectures du scrub concurrencent les lectures/écritures applicatives. Le débit du scrub devient une fonction des heures d’activité. Ce n’est pas une défaillance de ZFS ; c’est un échec de planification.

Signes que c’est de la contention :

La vitesse du scrub varie avec les motifs de trafic.
Les pics de latence se corrèlent aux heures de pointe applicatives.
Désactiver le scrub rend les utilisateurs à nouveau heureux.

4) Lenteur « quelque chose ne va pas »

C’est la catégorie qui vous intéresse vraiment. La lenteur du scrub devient un symptôme : un disque réessaie des lectures, un contrôleur signale des erreurs, un lien s’est négocié à 1,5 Gbps, un membre de vdev est malade et traîne tout le monde, ou vous avez construit une topologie de pool adaptée à la capacité mais mauvaise pour le scrub.

Signes d’un vrai problème :

Erreurs de lecture, erreurs de checksum, ou octets « réparés » qui augmentent d’un scrub à l’autre.
Un disque affiche une latence ou un débit bien plus faible que ses pairs.
Le taux de scrub s’effondre au fil du temps (commence normal, puis ralenti).
Les logs noyau montrent des resets, timeouts ou problèmes de lien.
Les attributs SMART montrent des secteurs réalloués/pending ou des erreurs UDMA CRC.

Le point clé : « lent » n’est pas un diagnostic. Vous chassez un goulot d’étranglement, puis vous demandez si ce goulot est attendu, configuré ou en train de tomber en panne.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand vous êtes en astreinte, vous n’avez pas le temps pour un long séminaire philosophique. Il vous faut un entonnoir rapide qui réduise le problème à l’une des catégories : attendu, contestation, throttling ou cassé.

Premier : le scrub est-il sain ?

Vérifiez le statut du pool pour des erreurs et le débit réel du scrub.
Cherchez tout membre de vdev dégradé, faulted ou avec « trop d’erreurs ».
Décision : si des erreurs existent, traitez cela comme un incident de fiabilité d’abord et une question de performance ensuite.

Deuxième : un périphérique traîne-t-il tout le vdev ?

Vérifiez la latence par disque et les temps de service I/O pendant le scrub.
Vérifiez SMART rapidement pour secteurs pending, erreurs média et CRC de lien.
Décision : si un disque est lent ou réessaie, remplacez-le ou isolez-le ; les scrubs sont le canari.

Troisième : contention ou throttling ?

Corrélez la vitesse du scrub avec les métriques workloads (IOPS, latence, profondeur de queue).
Vérifiez les tunables ZFS et si le scrub est volontairement limité.
Décision : si vous êtes limité, ajustez prudemment ; si c’est de la contention, replanifiez ou séparez les workloads.

Ce n’est qu’après ces trois étapes que vous abordez les questions d’architecture comme la largeur des vdevs, le recordsize, les vdevs spéciaux ou l’ajout de caches. Si le scrub est lent parce qu’un câble SATA est défaillant, aucune « optimisation » ne réparera la physique.

Tâches pratiques : commandes, signification des sorties et décision

Les tâches suivantes sont conçues pour être exécutées pendant qu’un scrub est actif (ou juste après). Chacune inclut une commande réaliste, une sortie exemple, ce que cela signifie, et la décision suivante. L’invite et les sorties sont illustratives, mais les commandes sont standard en environnements réels.

Task 1: Confirm scrub status, rate, and errors

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        12.3T scanned at 612M/s, 8.1T issued at 403M/s, 43.2T total
        0B repaired, 18.75% done, 2 days 09:14:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       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

errors: No known data errors

Ce que cela signifie : ZFS affiche à la fois « scanned » et « issued ». Issued est plus proche du taux réel d’achèvement des I/O physiques. Si issued est bien inférieur à scanned, vous pouvez observer du readahead, des effets de cache ou une attente sur des périphériques lents.

Décision : Si les compteurs READ/WRITE/CKSUM sont non nuls, cessez de considérer cela comme « juste lent ». Inspectez le(s) périphérique(s) défaillant(s) avant de tuner.

Task 2: Get one-line progress repeatedly (good for incident channels)

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        12.3T scanned at 612M/s, 8.1T issued at 403M/s, 43.2T total
        0B repaired, 18.75% done, 2 days 09:14:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0

Ce que cela signifie : C’est l’extrait minimal viable. Si l’ETA continue d’augmenter d’heure en heure, il y a probablement de la contention ou des lectures en réessai.

Décision : Si le taux issued est stable et que l’ETA diminue régulièrement, c’est probablement normal ou bridgé. Si cela fluctue énormément, passez aux vérifications par disque.

Task 3: Find which vdev layout you’re dealing with

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

        NAME                                   STATE     READ WRITE CKSUM
        tank                                   ONLINE       0     0     0
          raidz2-0                             ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...A1   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...B2   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...C3   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...D4   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...E5   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...F6   ONLINE       0     0     0

Ce que cela signifie : RAIDZ2 dans un vdev large. La vitesse de scrub sera limitée par le disque le plus lent et par l’overhead parité. Un disque défaillant peut ralentir tout le vdev.

Décision : Si vous avez un vdev RAIDZ très large et que les scrubs sont pénibles, vous pourriez envisager un changement architectural ultérieur (plus de vdevs, largeur réduite). Ne « tunez » pas la physique.

Task 4: Check per-disk latency and utilization during scrub (Linux)

cr0x@server:~$ iostat -x 2 3
Linux 6.6.12 (server)     12/25/2025  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.21    0.00    2.73    8.14    0.00   84.92

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s  w_await aqu-sz  %util
sda             112.0   28800.0     0.0   0.00   18.40   257.1      2.0     512.0   4.30   2.10  98.5
sdb             118.0   30208.0     0.0   0.00   17.92   256.0      2.0     512.0   4.10   2.12  97.9
sdc             110.0   28160.0     0.0   0.00   19.30   256.0      2.0     512.0   4.20   2.05  98.2
sdd              15.0    3840.0     0.0   0.00  220.10   256.0      1.0     256.0  10.00   3.90  99.1
sde             115.0   29440.0     0.0   0.00   18.10   256.0      2.0     512.0   4.00   2.08  98.0
sdf             114.0   29184.0     0.0   0.00   18.70   256.0      2.0     512.0   4.20   2.11  98.4

Ce que cela signifie : sdd a un r_await d’environ 220 ms alors que les autres sont à ~18 ms. C’est votre ancre de scrub. Le pool avancera au rythme du plus mauvais performeur dans un vdev RAIDZ.

Décision : Inspectez immédiatement sdd pour erreurs/logs/SMART. Si c’est un problème de câble ou de contrôleur, corrigez cela avant de remplacer le disque.

Task 5: Check kernel logs for resets/timeouts (Linux)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata|scsi|reset|timeout|error' | tail -n 12
[Wed Dec 24 13:18:44 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Wed Dec 24 13:18:44 2025] ata7.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 13:18:44 2025] ata7: hard resetting link
[Wed Dec 24 13:18:45 2025] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[Wed Dec 24 13:18:46 2025] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[Wed Dec 24 13:18:46 2025] sd 6:0:0:0: [sdd] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=14s
[Wed Dec 24 13:18:46 2025] blk_update_request: I/O error, dev sdd, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0

Ce que cela signifie : Reset de lien puis renégociation à 1.5Gbps est le classique « câble/backplane/port défaillant ». Cela peut aussi être un disque en fin de vie, mais les câbles sont moins chers et très courants.

Décision : Traitez comme une panne matérielle. Reseat/remplacez le câble ou changez de port. Puis revérifiez la latence par disque. Si les erreurs persistent, remplacez le disque.

Task 6: Quick SMART health check for the slow device

cr0x@server:~$ sudo smartctl -a /dev/sdd | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: PASSED
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       31245
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       27

Ce que cela signifie : Des secteurs pending et des Offline_Uncorrectable indiquent que le disque a du mal à lire certaines zones. Les erreurs UDMA CRC pointent souvent vers un câble/backplane défaillant. « PASSED » n’est pas une absolution ; c’est du marketing.

Décision : Si des pending/offline uncorrectable existent, planifiez le remplacement. Si les erreurs CRC augmentent, corrigez aussi le chemin physique (câble/backplane/HBA).

Task 7: Identify if the pool is doing repairs (and how much)

cr0x@server:~$ zpool status -v tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        14.8T scanned at 540M/s, 10.2T issued at 372M/s, 43.2T total
        256M repaired, 23.61% done, 2 days 05:01:12 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Ce que cela signifie : Un « repaired » non nul lors du scrub signifie que ZFS a trouvé des mismatches de checksum et les a corrigés. C’est le scrub qui fait son travail, mais c’est aussi la preuve d’une corruption quelque part (disque, câblage, contrôleur ou mémoire).

Décision : Si les réparations se répètent d’un scrub à l’autre, investiguez la cause racine. Une réparation ponctuelle après un événement connu peut être acceptable ; des réparations répétées ne le sont pas.

Task 8: Look for ZFS-level I/O and latency indicators (Linux)

cr0x@server:~$ sudo cat /proc/spl/kstat/zfs/arcstats | egrep '^(hits|misses|size|c_max|demand_data_misses|prefetch_data_misses) ' | head
hits                            2876543210
misses                          456789012
size                            17179869184
c_max                           34359738368
demand_data_misses              123456789
prefetch_data_misses            234567890

Ce que cela signifie : Les stats ARC indiquent si les lectures sont servies depuis la mémoire ou vont sur disque. Pendant un scrub, l’ARC peut être moins utile car les lectures du scrub ne sont pas toujours cache-friendly, mais une ARC minuscule avec des workloads lourds peut aggraver la contention.

Décision : Si l’ARC est à la diète et que la machine swappe, corrigez la pression mémoire en priorité. Ne blâmez pas le scrub pour un problème de RAM.

Task 9: Check pool I/O in real time (Linux with zpool iostat)

cr0x@server:~$ zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        28.1T  15.1T  3.10K    220   380M  12.1M
  raidz2-0  28.1T  15.1T  3.10K    220   380M  12.1M
    sda          -      -    520     35  63.5M  2.1M
    sdb          -      -    525     36  64.1M  2.1M
    sdc          -      -    518     35  63.2M  2.0M
    sdd          -      -    110     34  12.9M  2.0M
    sde          -      -    523     35  64.0M  2.1M
    sdf          -      -    524     35  64.3M  2.1M
----------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Encore une fois, sdd sous-performe par rapport aux autres. En RAIDZ, cela peut réduire le débit effectif et augmenter le temps de scrub.

Décision : Si un périphérique montre un débit/ops constamment inférieur, concentrez-vous là-dessus. Ne touchez pas aux tunables globaux tant que la parité des périphériques n’est pas restaurée.

Task 10: Confirm ashift and basic pool properties (performance baseline)

cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_tree' -n | head -n 8
64:        ashift: 12
120:    vdev_tree:
121:        type: 'root'
122:        id: 0

Ce que cela signifie : ashift: 12 implique des secteurs 4K. Si vous voyez ashift: 9 sur des disques 4K modernes, vous pouvez subir de l’amplification d’écritures et des comportements de performance étranges. Cela ne se verra pas toujours pendant un scrub (majoritairement lecture), mais cela peut empirer la performance générale du pool et l’overhead de resilver/scrub.

Décision : Si ashift est incorrect, la correction est généralement « reconstruire le pool correctement », pas « tuner plus ». Mettez-le sur la feuille de route.

Task 11: Check dataset compression and recordsize (workload interaction)

cr0x@server:~$ zfs get -o name,property,value -s local compression,recordsize tank/vmstore
NAME         PROPERTY     VALUE
tank/vmstore compression  lz4
tank/vmstore recordsize   128K

Ce que cela signifie : Pour des images VM, recordsize est souvent ajusté plus petit (comme 16K) selon les motifs I/O. Un grand recordsize n’est pas « faux », mais si votre workload est aléatoire 4K, vous pouvez générer plus de lectures par octet utile pendant le scrub et un surcoût opérationnel en général.

Décision : Ne changez pas recordsize imprudemment sur des données existantes. Mais si la douleur du scrub se corrèle à un dataset connu pour des I/O aléatoires petits, revoyez la conception du dataset pour la prochaine itération.

Task 12: Check for special vdevs (metadata) and their health

cr0x@server:~$ zpool status tank | egrep -n 'special|log|cache|spares' -A3
15:    special
16:      nvme0n1p2             ONLINE       0     0     0

Ce que cela signifie : Si vous avez un special vdev (souvent NVMe) stockant métadonnées/petits blocs, sa santé et sa latence peuvent dominer le comportement du scrub pour les pools riches en métadonnées. Un special vdev défaillant peut rendre l’ensemble du pool « lent » même si les HDD vont bien.

Décision : Si le scrub est lent sur un workload riche en métadonnées, vérifiez tôt la performance et les erreurs du special vdev.

Task 13: Check the actual device path and link speed (common hidden failure)

cr0x@server:~$ sudo hdparm -I /dev/sdd | egrep -i 'Transport|speed|SATA Version' | head -n 5
Transport: Serial, ATA8-AST, SATA 3.1
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 1.5 Gb/s)

Ce que cela signifie : Le disque supporte 6.0Gb/s mais est actuellement à 1.5Gb/s. C’est un fort indicateur de problèmes de lien, pas de « ZFS lent ».

Décision : Corrigez le chemin physique. Après réparation, confirmez la négociation à 6.0Gb/s et relancez iostat.

Task 14: Check scrub throttling-related module parameters (Linux OpenZFS)

cr0x@server:~$ sudo systool -m zfs -a 2>/dev/null | egrep 'zfs_scrub_delay|zfs_top_maxinflight|zfs_vdev_scrub_max_active' | head -n 20
  Parameters:
    zfs_scrub_delay        = "4"
    zfs_top_maxinflight    = "32"
    zfs_vdev_scrub_max_active = "2"

Ce que cela signifie : Ces valeurs influencent l’agressivité d’émission d’I/O du scrub. Plus agressif n’est pas toujours mieux ; vous pouvez augmenter la profondeur de queue et la latence pour les applications, et parfois ralentir le scrub à cause du thrash.

Décision : Si le scrub est lent mais sain et que vous avez de la marge (faible latence d’impact, faible util), envisagez un tuning. Si le système est déjà chaud, ne « réparez » pas en augmentant la bagarre I/O.

Task 15: Confirm TRIM and autotrim behavior (SSD pools)

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

Ce que cela signifie : Sur des pools SSD, autotrim peut affecter la performance à long terme. Pas directement la vitesse de scrub, mais cela change le comportement du pool sous lectures/écritures soutenues et GC, ce qui peut rendre les scrubs « aléatoirement horribles ».

Décision : Si vous êtes sur SSDs et observez des chutes périodiques de performance, évaluez l’activation d’autotrim dans une fenêtre de changement contrôlée.

Task 16: Check if you’re accidentally scrubbing frequently

cr0x@server:~$ sudo grep -R "zpool scrub" -n /etc/cron* /var/spool/cron 2>/dev/null | head
/etc/cron.monthly/zfs-scrub:4: zpool scrub tank

Ce que cela signifie : Les scrubs mensuels sont courants. Les scrubs hebdomadaires peuvent convenir pour des petits pools, mais sur de grands pools cela peut signifier que vous êtes effectivement toujours en train de scrubber, et les opérateurs finissent par ignorer le signal.

Décision : Choisissez une cadence adaptée au média et au risque. Si un scrub ne se termine jamais avant le suivant, vous avez transformé les vérifications d’intégrité en bruit de fond.

Trois mini-récits en entreprise depuis les tranchées du scrub

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster de virtualisation sur ZFS. Rien d’exotique : RAIDZ2, gros disques SATA, un pool par nœud. Les scrubs étaient programmés mensuellement et prenaient « un certain temps ». On s’y était habitué.

Puis un mois l’ETA du scrub a commencé à augmenter. Ce n’était pas dramatique au début — juste un jour de plus. La personne d’astreinte a supposé que c’était de la contention de workload : des jobs de fin de trimestre. On a laissé courir. « Les scrubs sont lents, ça finira par passer. »

Deux jours plus tard, la latence des VM a grimpé, redescendu, puis remonté. Zpool status affichait toujours ONLINE, aucune erreur évidente. L’hypothèse a tenu : « c’est occupé ». Personne n’a regardé les stats disque — erreur.

Quand quelqu’un a finalement lancé iostat -x, un disque affichait des r_await de 300–800 ms, alors que les autres étaient à 15–25 ms. SMART montrait des secteurs pending. Le disque ne mourait pas brutalement ; il mourait poliment en traînant le vdev. C’est le pire type car cela ressemble à de la « lenteur normale » jusqu’au moment où ce n’en est plus.

Ils ont remplacé le disque. Le taux de scrub est revenu à la normale immédiatement. La vraie leçon n’était pas « remplacer les disques plus vite ». C’était : ne supposez jamais que la lenteur du scrub est due au workload tant que vous n’avez pas vérifié que tous les périphériques sont sains. Le scrub touche parfois les mauvais secteurs en premier. C’est votre système d’alerte précoce. Servez-vous-en.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait des fenêtres de maintenance strictes. Ils voulaient que les scrubs se terminent pendant le weekend, coûte que coûte. Quelqu’un a trouvé les tunables de scrub et a décidé de « monter le volume ». Ils ont augmenté la concurrence et réduit les délais. Le scrub est devenu agressif, et le chiffre de débit avait l’air impressionnant — pendant environ une heure.

Puis la latence applicative a grimpé. Les hyperviseurs ont commencé à logger des stalls de stockage. Les utilisateurs se sont plaints lundi matin de « lenteurs aléatoires ». L’équipe a d’abord pointé le réseau (comme toujours), puis ZFS, puis l’hyperviseur. Triangle classique du déni.

Ce qui s’était réellement passé était plus ennuyeux : le pattern I/O du scrub a expulsé le cache du workload et a enfoncé les files disque. Les HDD ont atteint près de 100 % d’util, avec des temps de service élevés. Certaines lectures applicatives sont devenues des monstres de tail-latency. Le scrub lui-même n’a pas fini plus vite au global — car lorsque les queues ont grandi, le débit effectif a chuté et les réessais ont augmenté.

Ils ont annulé le tuning et déplacé les scrubs vers des périodes de faible trafic. L’« optimisation » était réelle, mais son impact système était négatif. L’astuce de performance la plus efficace en stockage reste la planification : ne forcez pas vos utilisateurs.

Blague courte #2 : Le tuning stockage, c’est comme la politique de bureau — si vous poussez trop fort, tout le monde ralentit et, étrangement, c’est quand même votre faute.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une équipe fintech utilisait OpenZFS sur Linux pour une charge de type grand livre. Les scrubs étaient traités comme une activité de maintenance formelle : programmés, monitorés et comparés à des baselines historiques. Pas d’héroïsme. Juste des graphiques et de la discipline.

Ils gardaient un runbook simple : après chaque scrub, enregistrer la durée, le débit moyen issued, et les octets réparés. Si « repaired » était non nul, cela déclenchait une vérification approfondie : logs noyau, SMART long test, et revue de tout changement matériel récent.

Un mois, un scrub s’est terminé avec une petite quantité réparée — rien d’alarmant en soi. Mais c’était le deuxième mois consécutif. Leur logique baseline l’a signalé. La personne d’astreinte a creusé et a trouvé des erreurs CRC intermittentes sur un chemin disque. Pas assez pour faire échouer le disque net, mais suffisant pour altérer des bits occasionnellement sous charge. Exactement le type de défaut qui vous ruine la journée six mois plus tard.

Ils ont remplacé le câble backplane et déplacé le disque vers un autre port HBA. Les réparations ont cessé. Pas d’incident, pas de perte de données, pas de rapport dramatique. C’est le genre de victoire qui n’est jamais célébrée parce que rien n’a explosé. Elle devrait l’être.

Erreurs fréquentes : symptôme → cause racine → correction

Cette section est volontairement directe. Ce sont des schémas qui reviennent en production, encore et encore, parce que les humains sont constants.

ETA du scrub qui augmente au fil du temps

Symptôme : L’ETA passe de « 12 heures » à « 2 jours » pendant le scrub.
Cause racine : Un périphérique réessaie des lectures (problèmes média) ou le lien clignote ; alternativement, la charge applicative a monté.
Correction : Lancez iostat -x et zpool iostat -v pour identifier un disque lent ; vérifiez dmesg et SMART. Si aucun disque solitaire n’est lent, corrélez avec la charge et replanifiez le scrub.

Le scrub est « lent » seulement pendant les heures ouvrées

Symptôme : Le scrub rampe de 9h à 17h et accélère la nuit.
Cause racine : Contention avec les workloads de production ; ZFS et/ou l’ordonnanceur OS priorisent l’I/O de premier plan.
Correction : Planifiez les scrubs sur des fenêtres de faible trafic ; préférez le throttling à l’agressivité. Ne montez pas la concurrence sans réflexion.

Un disque montre une attente 10× supérieure aux autres

Symptôme : Dans iostat -x, un lecteur a un r_await élevé ou un %util incohérent.
Cause racine : Disque mourant, comportement SMR sous stress, câble/backplane défectueux, port négocié à vitesse réduite.
Correction : Vérifiez dmesg et SMART, confirmez la vitesse de lien, changez câble/port, remplacez le disque si des secteurs pending ou des uncorrectables apparaissent.

Le scrub provoque des timeouts applicatifs

Symptôme : Pics de latence, timeouts, profondeur de file qui grandit ; le scrub semble « DoS » le système.
Cause racine : I/O du scrub trop agressive, mauvaise isolation des workloads, trop peu de vdevs, pool HDD servant des I/O aléatoires sans disques suffisants.
Correction : Réduisez l’agressivité du scrub ; replanifiez ; ajoutez des vdevs ou déplacez le workload vers SSD/NVMe ; envisagez un special vdev pour les métadonnées. Ne comptez pas sur un seul vdev RAIDZ large pour agir comme un array.

Le scrub rapporte des octets réparés de façon répétée

Symptôme : À chaque scrub, des données sont réparées.
Cause racine : Source chronique de corruption : disque défectueux, câble défaillant, contrôleur instable, ou problèmes mémoire (oui, la mémoire).
Correction : Inspectez le chemin matériel de bout en bout ; lancez des SMART long tests ; vérifiez les logs ECC si disponibles ; considérez une fenêtre de test mémoire contrôlée. Les données réparées sont un cadeau — ne l’ignorez pas.

Le scrub est lent sur un pool SSD « sans raison »

Symptôme : Pool NVMe/SSD plus lent que prévu, parfois avec des chutes périodiques.
Cause racine : Throttling thermique, GC SSD, mauvais comportement TRIM, problèmes de lien PCIe, ou goulot du special vdev.
Correction : Vérifiez températures et vitesse PCIe ; revoyez autotrim ; confirmez le firmware ; assurez-vous que le special vdev n’est pas saturé ou en erreur.

Le scrub ne se termine jamais avant le scrub suivant

Symptôme : Toujours en scrub ; les opérateurs finissent par ne plus y prêter attention.
Cause racine : Pool surdimensionné pour le média, cadence trop fréquente, ou scrub redémarré par automatisation.
Correction : Réduisez la cadence ; assurez-vous que les scrubs ne sont pas relancés inutilement ; envisagez des changements architecturaux (plus de vdevs, média plus rapide) si les vérifications d’intégrité ne finissent pas dans une fenêtre raisonnable.

La vitesse de scrub est bien inférieure aux calculs disques bruts

Symptôme : « Nous avons N disques, chacun fait X MB/s, alors pourquoi pas N×X ? »
Cause racine : Le scrub lit les blocs alloués, pas forcément séquentiels ; overhead métadonnées ; parité RAIDZ ; fragmentation ; et le pool peut être proche du plein, ce qui aggrave tout.
Correction : Comparez avec vos propres baselines historiques, pas les datasheets des vendeurs. Si proche du plein, libérez de l’espace. Si la fragmentation est sévère, envisagez une réorganisation planifiée via réplication vers un pool frais.

Checklists / step-by-step plans

Étape par étape : décider si un scrub lent est « normal »

Capturer le statut actuel. Lancez zpool status -v. Sauvegardez-le dans votre ticket/chat.
Recherchez des erreurs. Des compteurs READ/WRITE/CKSUM non nuls ou des octets « repaired » changent l’urgence.
Mesurez le taux issued. Si issued est stable et dans votre intervalle historique, c’est probablement normal.
Vérifiez la latence par disque. Utilisez iostat -x (Linux) et identifiez les outliers.
Consultez les logs. Une ligne dans dmesg sur des resets peut expliquer des jours de douleur de scrub.
Vérifiez SMART. Secteurs pending, uncorrectable et erreurs CRC décident du remplacement matériel.
Corrélez avec la charge. Si le scrub est lent seulement sous charge, corrigez la planification et/ou le throttling.
Ne tunez qu’ensuite. Et faites un changement à la fois avec un plan de rollback.

Étape par étape : si vous trouvez un disque lent pendant le scrub

Confirmez que c’est constant : iostat -x 2 5 et zpool iostat -v 2 5.
Vérifiez une négociation de lien réduite : hdparm -I pour SATA, ou logs contrôleur pour SAS.
Vérifiez les logs noyau pour resets/timeouts : dmesg -T filtré.
Vérifiez SMART : des secteurs pending/offline uncorrectable signifient vie empruntée.
Changez d’abord les éléments peu coûteux (câble/port) si le chemin pointe vers un problème de lien.
Remplacez le disque si des problèmes média sont présents ou si les erreurs persistent après correction du chemin.
Après remplacement, lancez un autre scrub ou au moins un plan de vérification ciblé conforme à vos standards opérationnels.

Étape par étape : si le scrub est sain mais perturbe la performance

Confirmez qu’aucun périphérique n’est malade (latence outlier, erreurs).
Confirmez si le scrub est déjà bridgé (vérifiez les tunables et la profondeur I/O observée).
Déplacez la planification du scrub vers des périodes de faible trafic ; étalez entre pools/nœuds.
Si vous devez scrubber pendant les heures ouvrées, bridez plutôt qu’accélérez.
Réévaluez la topologie du pool si vous ne pouvez pas compléter les scrubs durant une fenêtre de maintenance.

FAQ

1) Quelle est une vitesse « normale » pour un scrub ZFS ?

Normal, c’est ce que fait votre pool quand il est sain, faiblement chargé et sans erreurs. Utilisez votre propre durée historique de scrub et le débit issued comme baseline. Les spécifications séquentielles des disques ne sont pas une promesse pour le scrub.

2) Pourquoi `scanned` diffère de `issued` dans `zpool status` ?

« Scanned » reflète la progression logique à travers les blocs ; « issued » reflète l’I/O réellement envoyée/achetée aux vdevs. De gros écarts peuvent venir du cache, du readahead ou de l’attente sur des périphériques lents. Si issued est bas et la latence élevée, cherchez un disque traînant.

3) Un scrub lit-il l’espace libre ?

En général, le scrub vérifie les blocs alloués (ce qui est réellement utilisé). Ce n’est pas un scan de surface complet de chaque secteur. C’est pourquoi un disque peut encore cacher des secteurs défectueux qui ne se révéleront qu’à l’écriture ou à une lecture ultérieure.

4) Dois-je arrêter un scrub s’il est lent ?

Si le scrub est sain mais impacte les SLO de production, le mettre en pause/arrêter peut être raisonnable — puis le replanifier. Si vous constatez des erreurs ou des réparations, l’arrêter ne fait que retarder l’information dont vous avez probablement besoin. Traitez le problème matériel sous-jacent.

5) À quelle fréquence devrais-je lancer des scrubs ?

Une cadence courante est mensuelle pour de grands pools HDD, parfois hebdomadaire pour des environnements petits ou à risque élevé. La bonne réponse dépend du média, de la redondance et de la rapidité à laquelle vous voulez découvrir les erreurs latentes. Si la cadence dépasse votre capacité à terminer les scrubs, ajustez — ne normalisez pas « toujours en scrub ».

6) Le scrub a trouvé et réparé des données. Suis-je désormais en sécurité ?

Vous êtes plus en sécurité que si rien n’avait été fait, mais vous n’êtes pas « tiré d’affaire ». Les réparations signifient qu’une corruption a eu lieu sous ZFS. Si les réparations se répètent, réalisez une RCA (root cause analysis) sur disques, câbles, contrôleurs et potentiellement la mémoire.

7) RAIDZ est-il intrinsèquement lent au scrub comparé aux mirrors ?

Les mirrors sont souvent plus rapides et prévisibles pour les lectures car ils peuvent load-balancer et n’ont pas de reconstruction de parité pour lire. RAIDZ peut être très correct quand il est sain, mais des vdevs larges sont plus sensibles à un disque lent et aux patterns I/O aléatoires.

8) Le tuning peut-il rendre les scrubs dramatiquement plus rapides ?

Parfois modestement, si vous avez de la marge et des valeurs par défaut conservatrices. Mais le tuning n’est pas un substitut à plus de plateaux, du meilleur média ou à la correction d’un chemin disque défaillant. De plus : le tuning peut se retourner contre vous en augmentant la latence et en diminuant le débit effectif.

9) Pourquoi le scrub est lent sur un pool majoritairement vide ?

Parce que « vide » ne veut pas dire « simple ». Un pool avec des millions de petits fichiers, beaucoup de métadonnées, des snapshots ou une forte fragmentation peut scrubber lentement même si l’espace utilisé est faible. Le scrub touche les blocs alloués ; les allocations riches en métadonnées ne sont pas des bonbons séquentiels.

10) Quelle est la différence entre scrub et resilver, et pourquoi cela importe pour la lenteur ?

Le scrub vérifie les données existantes et répare la corruption ; le resilver reconstruit des données vers un périphérique remplacé/retourné. Le resilver a souvent une priorité et des patterns différents, et peut être plus orienté écriture. Confondre les deux vous fera mal interpréter attentes de performance et urgence.

Conclusion : étapes pratiques suivantes

Les scrubs lents ne sont pas intrinsèquement effrayants. En fait, un scrub lent sur un grand pool chargé est souvent le signe que ZFS se comporte de façon responsable. Ce qui est inquiétant, c’est la lenteur inexpliquée, surtout si elle vient avec des outliers par disque, des resets noyau ou des réparations récurrentes.

Utilisez cette séquence par défaut :

Lancez zpool status -v et décidez si c’est un événement de fiabilité (erreurs/repairs) ou un problème de planification/perf.
Lancez iostat -x et zpool iostat -v pour trouver le périphérique lent ou confirmer la contention.
Vérifiez dmesg et SMART pour les pannes évidentes du chemin matériel.
Ce n’est qu’ensuite que vous envisagez le tuning et la reprogrammation, et mesurez l’impact par rapport à votre baseline historique.

Une idée paraphrasée de W. Edwards Deming s’applique au travail opérationnel : « Sans données, vous n’êtes qu’une personne avec une opinion. » La lenteur d’un scrub est votre opportunité de collecter des données avant de collecter des pannes.