ZFS Scrub vs SMART Long Test : lequel détecte quoi

Le modèle mental : qui vérifie quoi

Commencez par la pile, parce que la confusion porte toujours sur les couches :

• SMART long test est le disque qui s’auto-vérifie : surface du média, correction d’erreurs interne, positionnement des têtes, stabilité des lectures et tout ce que le firmware du constructeur juge important. C’est une approche centrée sur le périphérique.
• Scrub ZFS est ZFS qui lit vos données et les vérifie par rapport aux checksums de bout en bout stockés dans les métadonnées, puis répare depuis la redondance si possible. C’est une approche centrée sur les données.

Ces points de vue se recoupent, mais pas suffisamment pour se reposer sur l’un seul. SMART peut vous indiquer qu’un disque se dégrade alors que ZFS n’a pas encore accédé aux zones faibles. ZFS peut vous indiquer que les données qui vous intéressent sont corrompues alors que SMART affirme que le disque est « PASSED ».

Opérationnellement : SMART est un signal prédictif. Le scrub est une garantie de correction. Vous voulez les deux parce que les systèmes de production échouent sur plusieurs dimensions, souvent en même temps.

Une citation qui devrait être tatouée sur chaque runbook de stockage : « L’espoir n’est pas une stratégie. » — James Cameron. Le stockage, c’est l’endroit où l’espoir vient mourir.

Ce que trouve (et répare) un scrub ZFS

Ce qu’un scrub fait, précisément

Un scrub ZFS est une lecture intentionnelle de l’ensemble du pool pour les blocs alloués, vérifiant le checksum de chaque bloc. Si ZFS trouve une discordance, il tente de réparer en récupérant une copie saine depuis la redondance (miroir/RAIDZ) et en réécrivant la copie défectueuse. Cette réparation n’est pas magique. Elle dépend de :

• La présence et la santé de la redondance.
• La défaillance limitée à un seul côté de la redondance (ou au moins ne dépassant pas la parité).
• La corruption étant détectable (discordance de checksum) plutôt qu’invisible (vous avez écrit les mauvais octets et en avez calculé le checksum).

Défaillances que les scrubs trouvent bien

Les scrubs excellent à détecter la corruption silencieuse des données dans le chemin protégé par ZFS. Cela inclut :

• Bit rot / erreurs de secteur latentes : des secteurs devenus illisibles ou renvoyant des données incorrectes ultérieurement.
• Mauvaises lectures que le disque considère « réussies » : le disque renvoie des données, mais elles sont incorrectes. ZFS le détecte car le checksum ne correspond pas.
• Problèmes de câblage/contrôleur qui entraînent des transferts corrompus (parfois signalés comme erreurs de checksum plutôt que comme erreurs de lecture).
• Erreurs de lecture irrécupérables durant le scrub : ZFS les consigne et peut réparer si la redondance existe.

Défaillances que les scrubs détectent mal

Un scrub n’est pas un « diagnostic de disque » et présente des angles morts :

• L’espace non alloué n’est pas lu. Un scrub ne testera pas les secteurs que ZFS n’a pas alloués.
• Échecs côté écriture peuvent passer inaperçus si de mauvaises données ont été écrites et checksummées comme correctes (c’est plus rare que ce que la peur suggère, mais cela existe dans l’univers des bugs, des écritures mal dirigées et des corruptions mémoire sans ECC).
• Mécanique du disque comme des seeks lents, des têtes marginales ou un cache défaillant peuvent se développer alors que votre working set courant se lit encore correctement.
• Timeouts transitoires pourraient ne pas se manifester pendant le scrub ; ou n’apparaître que sous un autre profil d’E/S.

Réalité sèchement drôle : un scrub, c’est comme auditer les dépenses de votre entreprise. Il trouve la fraude dans les reçus soumis, pas dans ce que personne n’a déclaré.

Ce que signifie réellement « scrub repaired X »

Si zpool status indique qu’un scrub a « réparé » des octets, vous avez appris exactement une chose : le pool a servi au moins une copie incorrecte d’un bloc, et ZFS a trouvé une autre copie saine. C’est une victoire pour l’exactitude, mais aussi un signal d’alarme. C’est la preuve d’un composant défaillant ou d’un problème de chemin. Votre travail est d’identifier lequel, avant que cela ne devienne une panne multi-disques lors d’un resilver.

Scrub vs resilver, car les gens confondent

Un scrub lit et valide les données allouées in situ. Un resilver est la reconstruction après remplacement ou rattachement d’un dispositif, copiant les données nécessaires pour restaurer la redondance. Les deux impliquent des lectures lourdes. Les deux peuvent révéler des secteurs latents. Mais l’intention diffère :

• Scrub : « prouver que les données existantes du pool sont correctes. »
• Resilver : « reconstruire la redondance et remplir un périphérique. »

Si vous n’apprenez l’existence d’erreurs de lecture latentes que pendant un resilver, vous avez appris trop tard.

Ce que détecte (et prédit) un test long SMART

Ce que font les tests longs SMART

Les auto-tests SMART sont des diagnostics pilotés par le firmware. Un test long (étendu) lit typiquement la majeure partie ou la totalité de la surface du périphérique (l’implémentation varie beaucoup), mettant à l’épreuve la capacité du disque à lire des secteurs et à corriger les erreurs en interne. Contrairement au scrub ZFS, il ne vérifie pas le checksum de vos données. Il vérifie la capacité du disque à récupérer les secteurs de façon fiable, avec son ECC interne et ses mécanismes de remappage.

Ce que SMART détecte bien

• Dégradation du média (secteurs en attente, secteurs réalloués, erreurs irrécupérables).
• Instabilité de lecture que le disque masque jusqu’à l’aggravation (augmentation des corrections d’erreurs, tentatives répétées, lectures lentes).
• Patrons de stress thermique corrélés aux pannes (historique de température, événements de surchauffe).
• Erreurs au niveau de l’interface (les erreurs CRC pointent souvent vers des problèmes de câblage/backplane plutôt que vers le média).

Ce que SMART ne détecte pas bien (surtout en 2025)

SMART n’est pas un oracle de vérité. C’est le firmware du constructeur qui vous dit comment il se sent aujourd’hui. Problèmes :

• La sémantique des attributs varie selon les constructeurs. Une valeur brute peut être « réelle » sur un disque et « calcul constructeur » sur un autre.
• SMART « PASSED » est un confort trompeur. Beaucoup de disques échouent sans jamais déclencher le drapeau global de santé.
• Les tests longs ne couvrent pas forcément tous les LBA sur certains appareils, ou peuvent être interrompus par des particularités de gestion d’énergie.
• Le comportement des SSD diffère : les « mauvais secteurs » deviennent un problème de couche de traduction, et certaines pannes se présentent comme une mort subite, pas une dégradation progressive.

Les tests longs SMART valent toujours la peine d’être lancés. Ne les utilisez simplement pas comme une carte « sortie de prison » quand ZFS commence à hurler.

Blague n°1 : SMART « PASSED » est comme un manager qui dit « tout a l’air bien » cinq minutes avant une réorganisation.

Comment les échecs SMART se traduisent en décisions opérationnelles

SMART vous donne un avertissement précoce, mais la décision n’est pas toujours « remplacer immédiatement ». Déclencheurs typiques :

• Tout Offline_Uncorrectable non nul ou tendance à la hausse : planifiez le remplacement. Ce disque produit des échecs durs.
• Reallocated_Sector_Ct en augmentation : remplacez bientôt, surtout si cela accompagne des secteurs en attente.
• Current_Pending_Sector non nul : considérez cela comme urgent ; un scrub/resilver le confrontera probablement et entraînera des échecs de lecture.
• UDMA_CRC_Error_Count en hausse : remplacez souvent le câble/le backplane en premier, pas le disque.

Recouvrements, lacunes et pourquoi les deux sont nécessaires

Le recouvrement : quand les deux outils sont d’accord

Parfois la vie est simple. Un disque est en train de lâcher, il produit des erreurs de lecture, SMART montre des secteurs en attente, et un scrub rapporte des erreurs de lecture ou des erreurs de checksum. Parfait. Vous remplacez le disque et passez à autre chose.

Lacune n°1 : SMART semble propre, ZFS rapporte des erreurs de checksum

Cela arrive fréquemment et effraie les gens. Ce n’est pas justifié. Les checksums sont de bout en bout : ils peuvent détecter la corruption causée par la RAM, des contrôleurs, des HBA, des câbles, des expanders, des backplanes, des firmwares, et même des caprices cosmiques. SMART ne connaît que ce que le disque voit en interne.

Si ZFS signale une « erreur de checksum », ne présumez pas que le disque ment. Considérez le chemin comme suspect jusqu’à preuve du contraire. Les problèmes de câble se manifestent souvent par des erreurs CRC dans SMART (SATA en particulier), mais pas toujours à temps.

Lacune n°2 : SMART semble mauvais, ZFS est silencieux

C’est le scénario de « défaillance latente ». Le disque se dégrade dans des zones que ZFS n’a pas lues récemment (données froides, datasets clairsemés, blocs non alloués). ZFS reste silencieux parce que rien ne lui a demandé de lire ces secteurs récemment. Un scrub les trouvera probablement — si le scrub est lancé avant qu’un resilver ne force des lectures sur toute la bande sous pression.

Lacune n°3 : les scrubs passent, mais vous perdez quand même des données

Les scrubs valident ce qui existe et ce qui est lisible. Ils ne garantissent pas :

• Que vos sauvegardes sont valides.
• Que votre matériel ne tombera pas en panne de façon catastrophique demain.
• Que vous disposez d’une redondance adaptée à votre domaine de défaillance (même lot de disques, même backplane, même bug de firmware).

Les scrubs réduisent le risque. Ils n’annulent pas les lois de la physique.

Ma règle d’opinion

Si vous exécutez ZFS en production et que vous ne planifiez ni scrubs ni tests longs SMART, vous ne « préservez pas l’usure ». Vous accumulez l’ignorance avec intérêt pour plus tard.

Faits intéressants et contexte historique

• ZFS a été livré avec le checksum de bout en bout dès le premier jour (ère Solaris), explicitement pour traiter la corruption silencieuse que les systèmes de fichiers traditionnels ne pouvaient pas détecter.
• Le terme « scrub » s’est popularisé dans le stockage via le RAID scrubbing : lectures périodiques pour trouver des erreurs de secteurs latents avant le temps de reconstruction, quand vous pouvez le moins vous permettre des surprises.
• SMART remonte aux années 1990, avec des implémentations spécifiques aux constructeurs avant qu’ATA ne standardise un ensemble de comportements de base.
• Le drapeau global de santé SMART « PASSED » est notoirement peu fiable ; beaucoup de défaillances surviennent sans le faire basculer, c’est pourquoi les SRE surveillent les attributs et les tendances.
• Les rapports de santé ATA et SCSI/SAS ont divergé : SAS utilise des log pages et des mécanismes de « self-test » qui ressemblent à SMART mais ne sont pas identiques.
• Les disques modernes peuvent réessayer les lectures de façon transparente, transformant un « mauvais secteur » en « secteur lent », qui se manifeste d’abord par des pics de latence, pas par des erreurs immédiates.
• Les scrubs ZFS ne lisent que les blocs alloués, donc un pool largement vide peut cacher des zones dégradées jusqu’à ce que les données croissent ou se déplacent.
• Les contrôleurs SSD remappent constamment ; les « secteurs » sont logiques, et les pannes peuvent être soudaines (firmware, corruption des métadonnées FTL) plutôt que graduelles.
• Le comportement de resilver RAIDZ nécessitait historiquement plus de lectures que les miroirs ; les fonctionnalités ZFS récentes comme le resilver séquentiel aident, mais les reconstructions stressent toujours la flotte.

Mode opératoire pour un diagnostic rapide

Ceci est la séquence « arrêtez de débattre dans le chat et trouvez le goulot ». Utilisez-la quand vous voyez des erreurs de checksum, des erreurs de lecture, des I/O lentes ou un scrub qui met une éternité.

Première étape : le pool est-il actuellement sûr ?

• Vérifiez zpool status -v : des vdevs sont-ils dégradés, des périphériques faulted, des erreurs irrécupérables ?
• Si la redondance est compromise (miroir dégradé, RAIDZ avec un disque mort), priorisez la restauration de la redondance plutôt que l’optimisation des performances.

Deuxième étape : disque, chemin ou hôte ?

• Disque : SMART montre pending/uncorrectable/reallocated en hausse ; ZFS montre des erreurs de lecture sur ce périphérique.
• Chemin : SMART montre des erreurs CRC ; ZFS montre des erreurs de checksum sur plusieurs disques derrière le même HBA/backplane ; dmesg montre des resets de lien/timeouts.
• Hôte : erreurs mémoire, événements ECC, avertissements noyau ou une mise à jour récente de pilote/firmware.

Troisième étape : êtes-vous lié par le débit ou par la latence maintenant ?

• Utilisez zpool iostat -v 1 pour voir quel vdev est saturé.
• Utilisez iostat -x pour repérer un périphérique avec un await/util élevé.
• Pendant un scrub : attendez-vous à des lectures intensives ; si le système s’effondre, limitez ou replanifiez.

Quatrième étape : Décidez—réparer, remplacer ou re-câbler

• Si c’est le média : remplacez le disque, puis scrub après le resilver.
• Si c’est le chemin : corrigez le câblage/backplane/HBA d’abord, puis scrub pour confirmer que les compteurs d’erreurs cessent d’augmenter.
• Si c’est l’hôte : validez la RAM (journaux ECC), passez en revue les changements récents et envisagez d’isoler le nœud.

Blague n°2 : Le moyen le plus rapide de « corriger » des erreurs de checksum est d’arrêter de vérifier — c’est aussi ainsi que l’on devient un cas d’école.

Tâches pratiques avec commandes, sens des sorties et la décision à prendre

Tous les exemples supposent un hôte Linux avec ZFS et smartmontools installés. Remplacez les noms de périphériques et de pools par votre réalité. L’essentiel est le flux de travail : observer → interpréter → décider.

Tâche 1 : Vérifier l’état du scrub et si les erreurs continuent à s’accumuler

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  see: zpool(8)
  scan: scrub repaired 128K in 02:13:44 with 0 errors on Tue Dec 24 03:11:09 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       2     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0

errors: No known data errors

Ce que ça signifie : le scrub a réparé des données, et un disque a des erreurs de lecture (READ=2). ZFS a corrigé en utilisant la parité, donc pas d’erreurs de données connues. C’est un avertissement.

Décision : extraire SMART pour le disque incriminé, vérifier le câblage/les logs HBA, et planifier le remplacement si SMART montre des pending/uncorrectable ou si les erreurs de lecture réapparaissent.

Tâche 2 : Vérifier si les erreurs de checksum sont localisées ou réparties

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:00:03 2025
        2.11T scanned at 1.02G/s, 1.44T issued at 711M/s, 18.2T total
        0B repaired, 0.00% done, 06:59:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-Samsung_SSD_...     ONLINE       0     0     0
            ata-Samsung_SSD_...     ONLINE       0     0     17

Ce que ça signifie : des erreurs CKSUM se trouvent sur une seule branche du miroir. Cela pointe plus vers ce périphérique ou son chemin (câble/backplane/HBA) que vers une corruption globale du pool.

Décision : vérifier SMART et les logs noyau pour ce périphérique ; si les CRC augmentent, suspecter le câblage ; si les erreurs média augmentent, remplacer.

Tâche 3 : Effacer les erreurs ZFS uniquement après avoir corrigé la cause

cr0x@server:~$ zpool clear tank

Ce que ça signifie : les compteurs sont réinitialisés. Ce n’est pas une correction ; c’est une façon de confirmer si le problème revient.

Décision : n’effacez qu’après avoir remplacé le matériel ou corrigé le chemin ; ensuite surveillez si le problème réapparaît lors du prochain scrub.

Tâche 4 : Lancer un scrub intentionnellement (évitez de le faire à midi le jour de la paie)

cr0x@server:~$ sudo zpool scrub tank

Ce que ça signifie : scrub mis en file/démarré. Sur des pools chargés, il concurrencera les charges de travail.

Décision : si le scrub provoque des douleurs de latence, ajustez la planification et examinez les choix zfs set (recordsize) séparément ; ne désactivez pas les scrubs.

Tâche 5 : Surveiller la progression du scrub et identifier le vdev lent

cr0x@server:~$ zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        9.12T  8.97T    512     44   820M  23.1M
  raidz2-0                  9.12T  8.97T    512     44   820M  23.1M
    ata-WDC_WD140EDFZ-1     -      -        82      7   131M  5.8M
    ata-WDC_WD140EDFZ-2     -      -        85      6   138M  5.2M
    ata-WDC_WD140EDFZ-3     -      -        19      6    12M  5.4M
    ata-WDC_WD140EDFZ-4     -      -        86      6   139M  5.3M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que ça signifie : un disque fournit beaucoup moins de bande passante de lecture que ses pairs (WD140EDFZ-3). C’est probablement votre goulot ou celui effectuant de nombreuses retransmissions.

Décision : inspecter SMART et les logs noyau pour ce disque ; planifier son remplacement s’il est lent à cause de réessais médias.

Tâche 6 : Lancer un test long SMART sur un disque SATA

cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 255 minutes for test to complete.
Test will complete after Wed Dec 25 06:14:02 2025

Ce que ça signifie : le disque a accepté le test ; il s’exécute dans le firmware pendant que les E/S continuent (mais peut impacter les performances).

Décision : planifiez les tests longs en heures creuses ; sur des baies chargées, échelonnez-les pour éviter des pics de latence synchronisés.

Tâche 7 : Lire les résultats du self-test SMART et décider si le remplacement est immédiat

cr0x@server:~$ sudo smartctl -a /dev/sda | sed -n '/Self-test execution status/,$p' | head -n 25
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever been run.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       00%     18432         723451233
# 2  Extended offline    Completed without error       00%     18390         -

Ce que ça signifie : une erreur de lecture est survenue à un LBA. Ce n’est pas « surveiller », c’est « ce disque ne peut pas lire une partie de sa surface de façon fiable ».

Décision : remplacez le disque. Avant remplacement, envisagez de forcer des lectures dans ZFS (scrub) pour voir si la redondance peut réécrire les blocs défectueux, mais ne misez pas la production dessus.

Tâche 8 : Vérifier les attributs SMART clés (HDD) pour signaux de défaillance latente

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
  5 Reallocated_Sector_Ct   0x0033   188   188   140    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Ce que ça signifie : des secteurs en attente et irrécupérables existent. Des secteurs ont déjà été réalloués. Le CRC est propre, donc probablement média, pas câblage.

Décision : remplacez le disque et lancez un scrub après le resilver pour vérifier qu’il n’y a pas d’erreurs résiduelles.

Tâche 9 : Détecter un problème de câblage/backplane via les erreurs CRC

cr0x@server:~$ sudo smartctl -A /dev/sdb | egrep 'UDMA_CRC_Error_Count|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       312

Ce que ça signifie : les erreurs CRC sont au niveau du transport. Les données ont été corrompues ou ont subi des réessais entre le disque et le contrôleur. Les disques restent souvent « sains » tandis que le lien est instable.

Décision : rebrancher/remplacer le câble, inspecter les connecteurs du backplane, permuter les ports sur l’HBA. Ne remplacez pas le disque en premier, à moins d’aimer perdre du temps.

Tâche 10 : Corréler les erreurs de périphérique ZFS aux périphériques physiques

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD140EDFZ | head
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0ABCD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0EFGH -> ../../sdd

Ce que ça signifie : vous mappez les noms by-id rapportés par ZFS aux périphériques noyau. Cela importe lors du remplacement des disques ; /dev/sdX n’est pas stable.

Décision : utilisez toujours /dev/disk/by-id pour les vdevs ZFS et dans votre procédure de remplacement.

Tâche 11 : Vérifier les logs noyau pour resets de lien et timeouts (problèmes de chemin)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]+|link is slow|hard resetting link|I/O error|blk_update_request' | tail -n 12
[Wed Dec 25 02:14:11 2025] ata7: hard resetting link
[Wed Dec 25 02:14:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 02:14:14 2025] blk_update_request: I/O error, dev sdc, sector 723451233 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Wed Dec 25 02:14:14 2025] ata7.00: failed command: READ FPDMA QUEUED

Ce que ça signifie : reset de lien + erreurs de lecture. Peut être un disque mourant, peut être une connexion flaky. Combinez cela avec SMART CRC et les secteurs en attente pour décider.

Décision : si le CRC augmente, traitez comme un problème de chemin ; si pending/uncorrectable augmente, traitez comme média. Si les deux augmentent, remplacez et le disque et le câble/backplane, car vous êtes dans la zone amusante.

Tâche 12 : Identifier si ZFS a des erreurs de données permanentes (le scénario cauchemardesque)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Restore the file in question if possible.
  scan: scrub completed after 07:44:02 with 0 errors on Thu Dec 26 04:12:09 2025
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      ONLINE       0     0     0
          raidz1-0                ONLINE       0     0     0
            ata-ST8000DM-1        ONLINE       0     0     0
            ata-ST8000DM-2        ONLINE       0     0     0
            ata-ST8000DM-3        ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/data/db/pg_wal/000000010000000A000000FE

Ce que ça signifie : la redondance n’a pas pu réparer un bloc corrompu. ZFS peut indiquer quel fichier a été affecté. Voilà précisément pourquoi vous exécutez ZFS.

Décision : restaurer depuis la sauvegarde ou la réplication au niveau applicatif ; enquêter pourquoi la redondance n’a pas suffi (RAIDZ1, multiples erreurs de lecture, problèmes silencieux antérieurs). Envisager d’augmenter la redondance pour cette charge.

Tâche 13 : Voir quels datasets consomment le plus de temps de scrub (méthode indirecte)

cr0x@server:~$ sudo zfs list -o name,used,logicalused,recordsize,compression -S used | head -n 10
NAME                 USED  LUSED  RECSIZE  COMPRESS
tank/data            6.12T  6.70T  128K     lz4
tank/backups         2.44T  2.80T  1M       lz4
tank/vm              1.91T  2.10T  16K      lz4
tank/home            312G   330G   128K     lz4

Ce que ça signifie : les datasets très utilisés dominent les E/S du scrub. Un petit recordsize (comme 16K pour des VMs) peut augmenter la métadonnée et la surcharge d’E/S.

Décision : ne « optimisez » pas le recordsize pendant un incident. Mais notez quels datasets pourraient justifier des pools séparés ou des agencements différents si les scrubs posent constamment problème.

Tâche 14 : Lancer un test long SMART sur un périphérique NVMe (self-test/log différent)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 2TB
Serial Number:                      S7HBNX0T123456A
Firmware Version:                   5B2QJXD7
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Read:                    12,384,921
Data Units Written:                 9,221,114
Media and Data Integrity Errors:     0
Error Information Log Entries:       0

Ce que ça signifie : la santé NVMe est différente : pourcentage utilisé, erreurs média, avertissements critiques. Il n’y a pas vraiment d’histoire de « secteur en attente » ; les pannes se manifestent souvent via des erreurs média ou des problèmes de contrôleur soudains.

Décision : suivez les erreurs media/data integrity et les entrées du journal d’erreurs NVMe dans le temps ; remplacez au moindre trend à la hausse, pas seulement quand le « critical warning » bascule.

Trois mini-récits du monde de l’entreprise

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

Ils avaient une règle simple : « Si SMART dit PASSED, le disque est bon. » Elle figurait dans le wiki on-call, était répétée lors des relais, et servait à clôturer rapidement les tickets. Le pool de stockage était en miroirs ZFS sur SSD SATA dans un châssis 2U, soutenant des services internes qui n’étaient jamais « critiques » jusqu’à ce qu’ils le deviennent.

Une semaine, ZFS a commencé à signaler des erreurs de checksum sur une branche du miroir. Pas d’erreurs de lecture. Pas d’erreurs d’écriture. Juste des incréments de checksum pendant le fonctionnement normal. SMART semblait propre. L’équipe a effacé les erreurs, lancé un scrub, vu « repaired 0B », et a lâché l’affaire. Le compteur de checksum a recommencé à augmenter. Même scénario : clear, hausse d’épaules, report.

Puis une mise à jour de firmware est arrivée pour l’HBA. Sous charge, la machine a commencé à journaliser des resets de lien. Soudain, la branche du miroir avec les erreurs de checksum est devenue indisponible pendant le trafic de pointe. L’autre branche a pris la charge, mais le pool s’est retrouvé un jour problématique d’un très mauvais week-end.

Le post-mortem a été franc : la mauvaise hypothèse n’était pas « SMART est utile ». La mauvaise hypothèse était que SMART est l’outil adéquat pour valider la correction des données. Les erreurs de checksum étaient un problème de chemin — probablement câblage/backplane marginal qui ne se manifestait que sous certains profils d’E/S. SMART ne l’a pas vu parce que le disque lui-même ne mourait pas. ZFS l’a vu parce que les données reçues ne correspondaient pas au checksum. La correction a été ennuyeuse : remplacer des câbles, reseater les connecteurs du backplane, et cesser d’effacer les compteurs tant que la cause n’était pas clarifiée. Après cela, les erreurs de checksum ont cessé.

Leçon : SMART PASSED ne contredit pas les checksums ZFS. Quand ils divergent, enquêtez sur le bus.

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

Une autre entreprise exploitait de grands pools RAIDZ2 ZFS pour des sauvegardes et du stockage objet. Les scrubs étaient mensuels parce que « ce sont des pools de données froides », et les tests longs SMART étaient désactivés parce que « ça ralentit les E/S ». Quelqu’un a eu une idée : les scrubs devraient être trimestriels, parce que les pools étaient larges et que les scrubs agaçaient les parties prenantes.

Pendant un moment, rien ne s’est passé. C’est le piège. Les erreurs de secteur latentes n’envoient pas d’invitation calendrier. Puis un disque est tombé et ils ont commencé un resilver. Pendant le resilver, un autre disque a commencé à générer des erreurs de lecture dans une région qui n’avait pas été touchée depuis des mois. Le pool a traîné, mais le resilver a ralenti car le disque répétait ses lectures. Finalement, ZFS a déclaré des erreurs irrécupérables sur une poignée d’objets de sauvegarde.

Ce n’étaient que des « sauvegardes », jusqu’à ce qu’elles ne le soient plus. Quand une restauration de production a été nécessaire plus tard, un sous-ensemble des points de récupération les plus anciens était corrompu. L’équipe applicative a dû choisir entre restaurer un snapshot plus récent (plus de perte de données) ou reconstruire l’état manuellement (plus de douleur). Ils ont fait les deux, mal.

L’optimisation reposait sur une mauvaise compréhension : les scrubs ne sont pas une maintenance optionnelle. Ils sont la façon dont ZFS convertit des défaillances latentes inconnues en blocs réparés tant que la redondance existe et que le pool est stable. Le temps de resilver est le pire moment pour découvrir des secteurs illisibles.

Ils sont revenus à des scrubs mensuels et ont échelonné les tests longs SMART hebdomadaires sur les périphériques. Les scrubs agaçaient toujours les parties prenantes, mais moins que la perte de données n’a agacé les dirigeants. C’est ainsi que les priorités se clarifient.

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

Une équipe gérant un cluster de virtualisation multi-tenant avait une routine simple et peu sexy : tests longs SMART hebdomadaires échelonnés par hôte, scrubs ZFS mensuels échelonnés par pool, et un tableau de bord suivant les deltas de trois attributs SMART : secteurs en attente, offline uncorrectable et erreurs CRC. Pas de machine learning sophistiqué. Juste des tendances.

Un lundi, le tableau de bord a montré une petite mais réelle augmentation du UDMA_CRC_Error_Count sur deux disques derrière le même backplane. Les disques n’avaient ni secteurs en attente ni secteurs réalloués. ZFS était propre. Les performances étaient normales. Personne n’était en alerte. C’est le moment où les équipes ignorent ou semblent paranoïaques.

Ils ont planifié une courte fenêtre de maintenance, reseated le connecteur du backplane, et remplacé deux câbles SATA. Les CRC ont arrêté d’augmenter. Aucun incident. Aucun downtime au-delà de la fenêtre. Tout le monde a oublié, ce qui est le bon résultat pour de la maintenance préventive.

Trois semaines plus tard, un autre hôte dans la même baie a eu un pattern CRC similaire. Ils ont remplacé les câbles à nouveau et découvert un problème de lot pour un modèle de câble spécifique. Ils les ont remplacés proactivement dans la flotte pendant des fenêtres de maintenance normales. Toujours aucun incident.

C’est à ça que ressemble le travail de fiabilité fait correctement : calme, répétitif et légèrement ennuyeux. C’est l’objectif.

Erreurs courantes (symptôme → cause → correction)

1) Symptom : les erreurs de checksum ZFS augmentent, mais SMART semble propre

Cause : corruption de transport ou réessais (câblage/backplane/HBA), parfois problèmes mémoire/pilote.

Correction : vérifier les compteurs CRC SMART, dmesg pour resets de lien, reseater/remplacer les câbles, déplacer le disque sur un autre port, envisager un rollback firmware/driver de l’HBA.

2) Symptom : le scrub a « réparé » des données et vous considérez le problème résolu

Cause : erreurs médias latentes ou instabilité de lecture intermittente ; vous avez eu de la chance parce que la redondance a encore fonctionné.

Correction : identifier quel périphérique a journalisé des erreurs de lecture/checksum ; lancer un test long SMART ; remplacer le disque suspect si les attributs sont non nuls ou si les erreurs récidivent.

3) Symptom : les scrubs durent une éternité et tuent la latence

Cause : scrubs en pleine heure de pointe ; un périphérique lent throttlant un vdev RAIDZ ; HDD SMR dans le mix ; ou disques effectuant de nombreux réessais internes.

Correction : planifier les scrubs en heures creuses ; échelonner entre les pools ; identifier les disques lents avec zpool iostat -v ; remplacer le récalcitrant ; éviter les SMR là où vous attendez des lectures régulières sous charge.

4) Symptom : SMART indique des secteurs en attente, mais le scrub ZFS est propre

Cause : les secteurs problématiques sont dans des zones que ZFS n’a pas lues récemment (ou jamais).

Correction : traiter les secteurs en attente comme urgents ; lancer un scrub (ou des lectures ciblées) pour forcer la détection/réparation ; planifier le remplacement du disque.

5) Symptom : « Permanent errors » dans zpool status

Cause : la corruption a dépassé la redondance, ou la corruption a été écrite et checksummée comme « valide », ou plusieurs périphériques ont renvoyé de mauvaises données.

Correction : restaurer les fichiers affectés depuis la sauvegarde/réplication ; augmenter le design de redondance (miroirs/RAIDZ2/3) et auditer l’intégrité mémoire (ECC) et le firmware du contrôleur.

6) Symptom : le test long SMART échoue ou s’interrompt répétitivement

Cause : problèmes média ; resets de périphérique ; particularités de gestion d’énergie ; ou le périphérique est derrière un contrôleur qui bloque le passage SMART.

Correction : exécuter SMART avec le bon type de périphérique (-d sat, -d megaraid,N, etc.) ; vérifier dmesg ; remplacer le disque en cas d’échecs de lecture avérés.

7) Symptom : vous remplacez un disque « mauvais » mais les erreurs continuent sur le nouveau

Cause : le chemin était en cause (câble/backplane/HBA), pas le disque.

Correction : investiguer les erreurs CRC et les resets de lien ; permuter de port/HBA ; valider l’alimentation ; ne sacrifiez pas les disques aux dieux du câble.

8) Symptom : le resilver échoue avec des erreurs de lecture depuis les disques survivants

Cause : erreurs de secteurs latentes découvertes sous la charge de reconstruction parce que les scrubs n’étaient pas assez fréquents.

Correction : augmenter la fréquence des scrubs ; remplacer les disques marginaux plus tôt selon les tendances SMART ; envisager une redondance plus élevée et des largeurs de vdev plus petites pour gérer le risque de reconstruction.

Check-lists / plan étape par étape

Politique de base (ZFS en production)

1. Activer des scrubs ZFS programmés par pool (mensuel est un bon défaut ; plus fréquent pour données chaudes ou grands pools HDD).
2. Planifier des tests longs SMART échelonnés par disque (hebdomadaire ou bimensuel ; tests courts quotidiens si vous voulez un signal rapide).
3. Alerter sur les erreurs ZFS : tout READ/WRITE/CKSUM non nul par périphérique, et tout octet « réparé ».
4. Alerter sur les tendances SMART : secteurs en attente, offline uncorrectable, croissance des réallocations, croissance CRC, erreurs media NVMe.
5. Documenter la procédure de remplacement en utilisant /dev/disk/by-id et inclure une étape de vérification post-remplacement par scrub/resilver.

Quand ZFS signale des erreurs de checksum

1. Exécuter zpool status -v, identifier le(s) périphérique(s) et si la redondance est dégradée.
2. Vérifier dmesg pour des resets/timeouts autour des horodatages.
3. Vérifier les attributs SMART, en particulier CRC, pending, uncorrectable et reallocated.
4. Si le CRC augmente : corriger câblage/backplane/HBA en premier.
5. Si pending/uncorrectable augmente : remplacer le disque.
6. Après correction : zpool clear, puis scrub, puis vérifier que les compteurs restent à zéro.

Quand un test long SMART échoue mais que ZFS est silencieux

1. Confirmer l’échec dans les logs self-test SMART et les attributs.
2. Lancer un scrub ZFS pour forcer les lectures des données allouées ; surveiller les erreurs de lecture/checksum.
3. Remplacer le disque même si ZFS ne se plaint pas encore, si le test long montre des échecs de lecture ou des uncorrectables.
4. Après remplacement/resilver : relancer un scrub pour confirmer la santé du pool.

Conseils de planification qui ne vous rendront pas détesté

• Échelonnez tout : ne lancez pas les scrubs de tous les pools à 01:00 le dimanche et les tests SMART à 01:05. Vous créerez votre propre incident.
• Préferez « lent prévisible » à « lent aléatoire » : un scrub programmé est ennuyeux ; un resilver non planifié est déterminant pour votre carrière.
• Surveillez la tendance des durées : si le temps de scrub double mois après mois, quelque chose a changé (capacité, charge, disque lent ou régression firmware).

FAQ

1) Si j’exécute des scrubs ZFS régulièrement, ai-je encore besoin des tests longs SMART ?

Oui. Les scrubs valident les données allouées ; SMART peut avertir d’une dégradation dans des zones que ZFS n’a pas touchées et révéler des problèmes de chemin via les compteurs CRC.

2) Si les tests longs SMART sont propres, puis-je ignorer les erreurs de checksum ZFS ?

Non. Les checksums sont de bout en bout. SMART peut être propre alors que le contrôleur, le câble, le backplane ou le pilote corrompent ou réessaient les E/S.

3) Les scrubs « usent »-ils les SSD ?

Les scrubs sont majoritairement des lectures ; les lectures ont un impact d’usure minimal comparé aux écritures. Le risque principal est l’impact sur les performances, pas l’endurance. Planifiez correctement.

4) Pourquoi un scrub a-t-il réparé des données mais SMART n’affiche aucune réallocation ?

Parce que la corruption peut ne pas être un défaut média déclenchant un remappage. Cela peut être une mauvaise lecture qui a passé les contrôles internes du disque, ou un problème de chemin.

5) À quelle fréquence devrais-je scrub ?

Mensuel est un bon défaut pour les pools HDD. Pour des pools très larges ou des données critiques, envisagez toutes les 2–4 semaines. Si les scrubs sont douloureux, corrigez l’architecture, pas le calendrier.

6) À quelle fréquence devrais-je lancer les tests longs SMART ?

Hebdomadaire ou bimensuel est raisonnable si vous échelonnez les disques. Pour les portables ou systèmes peu sollicités, mensuel suffit. Pour des baies, automatisez et gardez une régularité.

7) Quelle est la différence entre READ errors et CKSUM errors dans zpool status ?

Les READ errors signifient que le périphérique n’a pas pu fournir de données du tout. Les CKSUM errors signifient que des données ont été fournies mais ne correspondaient pas au checksum — souvent un problème de chemin ou de corruption.

8) Dois-je remplacer un disque avec quelques secteurs réalloués ?

Des réallocations ponctuelles stabilisées peuvent être tolérables, mais en production je remplace sur tendance : si le compteur augmente, ou si pending/uncorrectable apparaît.

9) Les scrubs peuvent-ils détecter une corruption en mémoire ou CPU ?

Indirectement. Si une mauvaise mémoire corrompt des données en transit ou à l’écriture, ZFS peut détecter des discordances ultérieures. La mémoire ECC réduit grandement ce risque ; sans ECC, vous jouez à la roulette.

10) Si le pool est RAIDZ1 et que je vois des octets réparés ?

Prenez-le au sérieux. RAIDZ1 a moins de marge pour des problèmes multi-secteurs ou multi-disques pendant les reconstructions. Envisagez d’augmenter la redondance si les données sont importantes.

Conclusion : prochaines étapes que vous pouvez faire cette semaine

Arrêtez de considérer le scrub ZFS et le test long SMART comme des outils concurrents. Ce sont des capteurs complémentaires pointant vers différentes parties du système : l’un valide vos données, l’autre interroge le périphérique.

1. Programmez des scrubs mensuels par pool et échelonnez-les dans votre flotte.
2. Programmez des tests longs SMART hebdomadaires/bimensuels, échelonnés par disque, et alertez sur les attributs qui prédisent réellement les problèmes (pending, uncorrectable, reallocations, CRC).
3. Quand ZFS signale des erreurs de checksum, enquêtez d’abord sur le chemin — câbles, backplane, HBA, firmware — puis sur le disque.
4. Quand SMART signale pending/uncorrectable, n’attendez pas un resilver pour découvrir la réalité. Remplacez le disque quand vous le pouvez.
5. Après toute correction, effacez les compteurs, lancez un scrub et confirmez que les erreurs cessent. Des preuves valent mieux que l’optimisme.

Votre futur vous appellera encore. Mais ce sera pour quelque chose de nouveau, pas pour la même tragédie de stockage évitable avec un autre horodatage.