ZFS zpool initialize : faire en sorte que les nouveaux disques se comportent bien dès le premier jour

Ce que fait réellement zpool initialize (et ce qu’il ne fait pas)

À un niveau élevé, zpool initialize écrit sur l’ensemble de l’espace d’adressage des vdevs de premier niveau dans une pool. Considérez-le comme un préconditionnement : il force la pool à toucher toutes les régions des disques pour que vous ne soyez pas surpris plus tard lorsque des zones froides, jamais écrites, se comporteront différemment des parties «chaudes» que vous avez pu mesurer au benchmark.

Sur de nombreux périphériques de stockage—surtout les SSD, mais aussi certains comportements SMR modernes et des optimisations de firmware—les performances changent après que le périphérique a été écrit de bout en bout au moins une fois. Tout juste sorti de la boîte, le disque peut sembler plus rapide parce qu’il n’a pas encore eu à faire la maintenance interne qu’il sera finalement obligé d’effectuer. Une fois que vous écrivez largement dessus, vous le poussez vers l’«état stable», qui est ce avec quoi vous vivrez pendant des années.

Initialize n’est ni scrub ni resilver

• Scrub lit et vérifie les blocs de données existants et les répare en utilisant la redondance. Il concerne l’intégrité des données déjà écrites.
• Resilver reconstruit les données manquantes sur un disque de remplacement, à partir des blocs alloués. Il concerne la restauration de la redondance.
• Initialize consiste à écrire sur le périphérique pour éviter les surprises du type «première écriture dans cette région» sous charge de production.

Initialize ne corrige pas non plus magiquement une mauvaise conception. Si vous avez construit une pool avec le mauvais ashift, un vdev à parité unique pour une charge d’écriture intensive, ou un HBA avec un firmware défectueux, l’initialisation ne vous absoudra pas. Elle vous aidera simplement à découvrir la douleur plus tôt, ce qui reste un avantage.

Une vérité opérationnelle tranchante : initialize est un brûlage contrôlé. Vous dépensez des I/O maintenant pour éviter des I/O chaotiques plus tard.

Pourquoi vous devriez vous en soucier : la falaise de latence

La plupart des incidents de performance en stockage ne concernent pas le débit. Ils concernent la latence en queue : le 99e et le 99,9e percentile. Les bases de données ne tombent pas parce que les écritures moyennes sont à 1 ms ; elles tombent parce qu’une petite fraction atteint 200 ms, s’accumule et transforme votre profondeur de file d’attente en embouteillage.

Voici le pattern classique sur une pool toute neuve :

• Vous testez avec fio sur une pool vide : latence impressionnante et stable.
• Vous mettez en production : toujours correct pendant un moment, car vous écrivez séquentiellement dans de l’espace neuf.
• Vous franchissez un seuil : l’allocation se disperse, le churn des métadonnées augmente, et le périphérique lance la collecte ou le remappage interne.
• Des pics de latence apparaissent de façon aléatoire, et vous ne pouvez pas facilement les reproduire en laboratoire parce que votre pool de test est toujours «trop vide» ou «trop neuve».

Initialize réduit le nombre d’événements «première fois que nous touchons cette région». Ce n’est pas une solution miracle, mais c’est l’un des rares outils qui vous aide à provoquer les problèmes de performance quand cela vous arrange.

Blague #1 : Les nouveaux SSDs font des benchmarks comme des stagiaires—rapides, enthousiastes et complètement non éprouvés sous vraie pression.

La version opérationnelle de «l’état stable»

Les ingénieurs disent souvent «état stable» comme si c’était un concept mathématique propre. En production, cela signifie : la pool a subi suffisamment d’écritures, de TRIMs, d’écrasements et de churn de métadonnées pour qu’elle cesse de changer de personnalité chaque semaine. Initialize vous aide à l’atteindre avant que vos clients ne le fassent pour vous.

Si vous administrez de larges pools ZFS pour des bases de données, des flottes de VM, des stockages d’objets ou des plates-formes de logs, vous vous souciez de la prévisibilité. L’initialisation vise la prévisibilité.

Faits intéressants et un peu d’histoire

Le stockage est un débat de longue haleine entre la physique et le marketing. Quelques points de contexte aident à expliquer pourquoi zpool initialize existe et pourquoi il compte.

1. ZFS a été conçu pour traiter les disques comme peu fiables. Le checksum de bout en bout et l’auto-réparation sont des fonctionnalités centrales, pas des suppléments.
2. «Scrub» précède «initialize» comme habitude opérationnelle. Le scrub est né du besoin de détecter proactivement des erreurs latentes de secteurs avant qu’un second disque ne tombe en panne.
3. La performance des SSD est notoirement différente «neuve» vs «usée». Beaucoup de contrôleurs maquillent les performances en écrivant d’abord dans des couches vides ; plus tard, vous payez le coût du nettoyage interne.
4. TRIM/UNMAP a changé la donne. Avant le support généralisé du TRIM, les SSD pouvaient rester «sales» ; maintenant l’hôte peut indiquer au disque quels blocs sont libres, mais le comportement varie toujours.
5. La douleur des reconstructions RAID a façonné les opérations modernes. Les longueurs de resilver et les fenêtres de reconstruction sont devenues un risque à mesure que la capacité des disques augmentait. Initialize n’accélère pas directement le resilver, mais il vous aide à observer le comportement des vdevs tôt.
6. Le firmware moderne des HDD a une mise en cache et une gestion de zones complexes. Même les disques conventionnels peuvent adopter des stratégies qui se comportent différemment sur des zones «jamais écrites» vs «déjà écrites».
7. Le comportement d’allocation ZFS change à mesure que les pools se remplissent. La fragmentation et la sélection des metaslabs évoluent ; les performances en début de vie ne sont pas représentatives.
8. La portabilité d’OpenZFS a modifié des détails d’implémentation. Des fonctionnalités comme l’initialisation ont évolué selon les plateformes, et le comportement/la disponibilité dépendent de la version d’OpenZFS et de l’intégration OS.

Une idée paraphrasée à garder en tête vient de John Ousterhout (Stanford, ingénieur systèmes) : idée paraphrasée : les problèmes de performance proviennent de ce que vous n’avez pas mesuré, pas de ce que vous avez mesuré. Initialize est une façon de mesurer l’avenir maintenant.

Quand lancer initialize (et quand ne pas le faire)

Le lancer quand

• Nouvelle pool, charge réelle bientôt. Surtout si la latence compte et que la pool va se remplir rapidement.
• Après remplacement de disques dans un vdev, quand vous voulez que le média de remplacement soit «réchauffé» sur tout son espace avant les heures de pointe.
• Après des changements matériels (nouvel HBA, mise à jour de firmware) quand vous voulez détecter tôt des timeouts étranges et des chemins lents.
• Avant une bascule de migration. Vous voulez un comportement prévisible pendant les premiers jours de production, pas des tempêtes de GC surprises.

Être prudent ou sauter quand

• Vous êtes déjà contraint en IOPS. L’initialisation ajoute une charge d’écriture. Sur des pools occupés, cela peut amplifier la douleur.
• Vous le faites «juste parce que». Si vous ne pouvez pas expliquer le mode de défaillance que vous évitez, vous le lancerez au mauvais moment et accuserez ZFS d’avoir fait exactement ce que vous avez demandé.
• Vous dépendez des marges d’endurance d’écriture. Initialize écrit beaucoup. Sur des SSD grand public à endurance limitée, ce n’est pas gratuit. Décidez consciemment.

Initialize vs alternatives (et pourquoi j’aime toujours initialize)

Des gens essaient de reproduire l’initialisation avec dd, fio, ou en remplissant un dataset de zéros. Cela «fonctionne» dans le sens où vous écrivez le disque, mais c’est souvent moins contrôlé et moins intégré à ZFS. Initialize est conscient de la pool et conçu pour ce travail.

Cela dit : l’initialisation ne remplace pas la planification. Choisissez une redondance sensée, paramétrez correctement ashift, ne surchargez pas les HBAs, et n’attachez pas une pool à un contrôleur qui croit que la récupération d’erreurs signifie «méditer pendant 120 secondes».

Tâches pratiques : commandes, sorties, décisions

Ci‑dessous des tâches éprouvées sur le terrain que j’utilise lors de la mise en service ou de la stabilisation de pools. Chacune contient : la commande, ce que signifie une sortie typique, et la décision que j’en tire. Si vous les exécutez dans l’ordre, vous éviterez la panique du type «on a lancé initialize et la pool est devenue lente» parce que vous saurez ce que «lent» était avant de commencer.

Task 1: Confirm OpenZFS and feature support

cr0x@server:~$ zfs version
zfs-2.2.4-0ubuntu1
zfs-kmod-2.2.4-0ubuntu1

Ce que cela signifie : Vous êtes sur OpenZFS 2.2.x ; l’initialisation est prise en charge sur les builds OpenZFS modernes (les spécificités de plateforme varient).

Décision : Si vous êtes sur un ZFS très ancien (ou une branche fournisseur), confirmez que zpool initialize existe et se comporte comme attendu avant de le parier en production.

Task 2: Inventory pools and health before touching anything

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  10.9T  1.23T  9.67T        -         -     2%    11%  1.00x  ONLINE  -

Ce que cela signifie : La pool est peu utilisée, faible fragmentation, saine.

Décision : L’initialisation sur une pool principalement vide est le moment le plus simple. Sur une pool presque pleine ou très fragmentée, planifiez soigneusement et surveillez la latence en queue.

Task 3: Get vdev topology and record device IDs (not just /dev/sdX)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:54 with 0 errors on Sun Dec 15 03:10:41 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1234  ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1235  ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1236  ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1237  ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1238  ONLINE       0     0     0
            ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1239  ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Les dispositifs sont référencés par des identifiants stables. Bien.

Décision : Si vous voyez des noms /dev/sdX, corrigez cela avant toute maintenance. L’énumération des périphériques change au gré des démarrages Linux.

Task 4: Check ashift indirectly (sector sizes) before blaming performance

cr0x@server:~$ zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
49:        vdev_tree:
68:                ashift: 12

Ce que cela signifie : ashift=12 implique des secteurs 4K. C’est habituellement correct pour les périphériques modernes.

Décision : Si vous découvrez ashift=9 sur des périphériques natifs 4K, corrigez la conception de la pool (habituellement reconstruire). Initialize ne sauvera pas un mauvais alignement.

Task 5: Baseline latency and throughput before initialize

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.23T  9.67T     12     85   2.1M  48.3M
  raidz2-0  1.23T  9.67T     12     85   2.1M  48.3M
    ...         -      -      2     14   350K   8.2M
    ...         -      -      2     14   360K   8.1M
----------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Vous avez une ligne de base. Vous ne devinez pas plus tard.

Décision : Si les écritures de base sont déjà contraintes, planifiez l’initialisation en dehors des heures et envisagez de limiter le débit via les contrôles I/O système (cgroups/ionice) plutôt que d’espérer que «ça n’ira pas trop mal».

Task 6: Check for existing background work (scrub/resilver) before starting

cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:54 with 0 errors on Sun Dec 15 03:10:41 2025
config:
...

Ce que cela signifie : Pas de scrub/resilver en cours.

Décision : Ne pas empiler des opérations de fond lourdes. Si un resilver est en cours, la priorité est la restauration de la redondance, pas le préconditionnement.

Task 7: Start initialization (whole pool)

cr0x@server:~$ sudo zpool initialize tank

Ce que cela signifie : La commande retourne rapidement ; l’initialisation s’exécute de façon asynchrone.

Décision : Commencez immédiatement à surveiller. Si vous «lancez et oubliez», vous découvrirez plus tard qu’elle est entrée en collision avec un job batch et vous accuserez la mauvaise chose.

Task 8: Verify initialization is actually running

cr0x@server:~$ zpool status tank | sed -n '1,35p'
  pool: tank
 state: ONLINE
  scan: initialize in progress since Mon Dec 22 10:14:09 2025
        1.12T scanned at 5.43G/s, 312G issued at 1.50G/s, 10.9T total
        0B initialized, 2.78% done, 02:01:18 to go
config:
...

Ce que cela signifie : Vous voyez «initialize in progress» avec progression et ETA. Notez que «scanned» et «issued» sont différents ; issued représente la vraie charge d’écriture.

Décision : Si la progression est bloquée (ETA qui augmente, issued proche de zéro), suspectez des timeouts périphériques, une famine de queues, ou des charges concurrentes.

Task 9: Pause initialization when production is burning

cr0x@server:~$ sudo zpool initialize -s tank

Ce que cela signifie : Arrête (suspend) la scan d’initialisation.

Décision : Utilisez ceci lorsque les budgets de latence sont violés. Ne pas «forcer» sur un système chaud ; vous créerez un incident plus grave que celui que vous tentiez d’éviter.

Task 10: Resume initialization

cr0x@server:~$ sudo zpool initialize tank

Ce que cela signifie : Reprend là où c’était arrêté.

Décision : Reprenez pendant des fenêtres plus calmes. Si votre charge n’a jamais de fenêtres calmes, c’est un problème de capacity planning, pas un problème ZFS.

Task 11: Initialize only a specific vdev (surgical preconditioning)

cr0x@server:~$ sudo zpool initialize tank ata-SAMSUNG_MZ7L33T8HBLA-00007_S6Y0NX0W1238

Ce que cela signifie : Cible le vdev feuille nommé (dépend de la plateforme/version ; l’adressage topologique doit correspondre à zpool status).

Décision : Utile après remplacement d’un disque dans un mirror/groupe raidz quand vous voulez que le nouveau cesse de se comporter comme un appareil flambant neuf pendant que ses pairs sont «assaisonnés».

Task 12: Watch per-disk behavior while initialize runs

cr0x@server:~$ iostat -x 1 5
Linux 6.8.0-48-generic (server)  12/22/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.88    6.44    0.00   88.56

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  svctm  %util
sda              0.00  180.00    0.00 184320.0   2048.0     8.20   45.6   5.1   92.0
sdb              0.00  177.00    0.00 181248.0   2048.0     8.10   46.2   5.2   91.4

Ce que cela signifie : Un %util élevé et un await élevé sont attendus lors d’écritures séquentielles lourdes, mais surveillez qu’un disque n’ait pas un await beaucoup plus élevé que ses pairs.

Décision : Si un disque est un outlier, considérez-le comme matériel/firmware suspect ou un problème de chemin (lane SAS, expander, câble). L’initialisation est un excellent moyen d’extraire ce type de problème.

Task 13: Confirm TRIM support and whether it’s enabled (SSD pools)

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

Ce que cela signifie : Autotrim est désactivé. Ce n’est pas automatiquement mauvais, mais c’est un choix délibéré.

Décision : Pour beaucoup de pools SSD, activer autotrim aide la performance à long terme en état stable. Si vous l’activez, surveillez tout comportement étrange du firmware et toute régression de performance dans votre environnement.

Task 14: Turn on autotrim (if you decide it’s right)

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

Ce que cela signifie : ZFS émettra des TRIM pour les blocs libérés (les détails d’implémentation varient selon l’OS et la version d’OpenZFS).

Décision : Faites-le lorsque vous avez confiance dans le firmware des SSD et que vous voulez une performance cohérente à long terme. Si vos SSD sont connus pour mal se comporter avec TRIM sous charge, laissez-le désactivé et comptez sur des trims manuels périodiques pendant des fenêtres de maintenance.

Task 15: Monitor ZFS latency indicators via zpool iostat

cr0x@server:~$ zpool iostat -l -v tank 1 3
                              operations     bandwidth
pool                         read  write   read  write
---------------------------  -----  -----  -----  -----
tank                            10    950  1.2M  1.10G
  raidz2-0                      10    950  1.2M  1.10G
    ata-...1234                  2    160  120K  190M
    ata-...1235                  2    158  110K  188M
---------------------------  -----  -----  -----  -----

Ce que cela signifie : Bande passante d’écriture importante cohérente avec l’initialisation. Si les lectures restent faibles et que la latence applicative souffre, vous pourriez saturer les mêmes files utilisées pour les I/O de premier plan.

Décision : Si les lectures de premier plan sont affamées, arrêtez ou replanifiez l’initialisation. «Mais l’initialisation est séquentielle» n’est pas une garantie qu’elle ne nuira pas aux lectures aléatoires.

Task 16: Validate error counters during initialize

cr0x@server:~$ zpool status -v tank | sed -n '1,80p'
  pool: tank
 state: ONLINE
  scan: initialize in progress since Mon Dec 22 10:14:09 2025
        6.02T scanned at 4.91G/s, 1.88T issued at 1.53G/s, 10.9T total
        0B initialized, 17.2% done, 01:38:02 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            ata-...1234                                 ONLINE       0     0     0
            ata-...1235                                 ONLINE       0     0     0
            ata-...1236                                 ONLINE       0     0     0
            ata-...1237                                 ONLINE       0     0     0
            ata-...1238                                 ONLINE       0     0     0
            ata-...1239                                 ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Pas d’erreurs de lecture/écriture/checksum pendant le martèlement des disques. C’est exactement ce que vous voulez découvrir tôt.

Décision : Tout compteur d’erreurs qui s’incrémente pendant l’initialisation est un cadeau. Traitez-le comme un avertissement précoce et commencez à isoler les chemins matériels avant d’y confier des données.

Task 17: Correlate kernel logs for resets/timeouts

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Mon Dec 22 10:41:02 2025] sd 2:0:12:0: [sdl] tag#8121 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Mon Dec 22 10:41:02 2025] sd 2:0:12:0: [sdl] tag#8121 CDB: Write(16) 8a 00 00 00 00 1a 5f 2b 40 00 00 02 00 00 00
[Mon Dec 22 10:41:03 2025] blk_update_request: I/O error, dev sdl, sector 442446848 op 0x1:(WRITE) flags 0x0 phys_seg 32 prio class 0

Ce que cela signifie : Le kernel voit des timeouts et des erreurs d’écriture sur un périphérique. ZFS peut réessayer ; votre application verra des pics de latence ; vos fenêtres de resilver deviendront cauchemardesques.

Décision : Arrêtez l’initialisation, examinez câblage/HBA/expander/firmware du disque, et lancez des diagnostics SMART et de liaison ciblés. Ne continuez pas à écrire en espérant que le problème «s’échauffera». C’est comme ça qu’on finit un vendredi soir en urgence.

Task 18: Check SMART health and error logs (SATA example)

cr0x@server:~$ sudo smartctl -a /dev/sdl | sed -n '1,40p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-48-generic] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     SAMSUNG MZ7L33T8HBLA-00007
Serial Number:    S6Y0NX0W1238
Firmware Version: EDA7202Q
User Capacity:    3,840,755,982,336 bytes [3.84 TB]
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
...

Ce que cela signifie : Vous pouvez confirmer la version du firmware et la santé de base. Les parties intéressantes se trouvent généralement dans le journal d’erreurs et les indicateurs d’usure média plus bas.

Décision : Si le firmware est connu pour poser problème dans votre flotte, standardisez. Un firmware mixte dans un vdev est une façon subtile de créer des douleurs subtiles.

Task 19: Observe pool space and fragmentation as it fills (initialize doesn’t fix this)

cr0x@server:~$ zpool list -o name,size,alloc,free,cap,frag,health tank
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  10.9T  1.23T 9.67T 11%  2%    ONLINE

Ce que cela signifie : Faible fragmentation et faible utilisation de capacité. Vous avez de la marge.

Décision : Si vous opérez régulièrement au‑dessus d’environ 80% de capacité sur des pools actives, votre vrai problème de performance est le manque d’espace contigu et la contrainte des metaslabs. Initialize ne changera pas cela.

Playbook de diagnostic rapide

Vous avez lancé zpool initialize (ou vous avez hérité d’un système où c’est en cours), et la latence est mauvaise. Vous devez répondre rapidement à une question : est‑ce que l’initialisation est le goulot d’étranglement, ou expose‑t‑elle simplement un maillon faible ?

Premier point : confirmez le travail de fond actif

• Lancez zpool status. Si vous voyez initialize in progress, vous avez trouvé une source importante de charge d’écriture.
• Vérifiez si un scrub ou un resilver est aussi en cours. Si oui, arrêtez le moins critique.

cr0x@server:~$ zpool status -x
all pools are healthy

Décision : La santé n’est pas la performance. «Healthy» signifie uniquement qu’il n’y a pas de corruption ou de défaillance connue pour l’instant. Poursuivez.

Second point : déterminez si le goulot est un seul disque/chemin ou tout le vdev

• Utilisez iostat -x ou zpool iostat -v et repérez un périphérique avec un await bien pire ou un débit bien plus bas.
• Si un périphérique est lent, il traîne le vdev. RAIDZ et mirrors paient tous deux pour le membre le plus lent de différentes manières.

Troisième point : vérifiez les logs kernel pour les resets/timeouts

• Les time‑outs dans dmesg sont souvent le véritable coupable. L’initialisation augmente juste la probabilité de les voir.
• Les tempêtes de reset se corrèlent souvent avec un emplacement, un câble, un port d’expander ou un problème d’alimentation spécifique.

Quatrième point : vérifiez que vous ne saturez pas simplement les files

• Si tous les disques montrent une haute utilisation sans erreurs, vous atteignez peut‑être les limites de bande passante/IOPS.
• Arrêtez ou suspendez initialize, confirmez que la latence revient à la normale, puis replanifiez-initialize hors‑pic.

Cinquième point : sanity-check des choix de conception de la pool

• Un mauvais ashift cause des douleurs permanentes et structurelles.
• Les mismatches recordsize/volblocksize ne casseront pas initialize, mais peuvent induire en erreur vos conclusions de performance.
• Opérer à des taux de remplissage élevés rend tout pire, toujours.

Ce playbook n’est pas glorieux, mais il est rapide. Vous essayez de décider s’il faut suspendre initialize, remplacer du matériel, ou accepter que le système fait exactement autant d’I/O qu’il le peut.

Trois mini-récits d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse

L’entreprise avait un plan de migration propre : nouvelle pool ZFS sur SSD, répliquer les datasets, basculer pendant un dimanche calme. Ils ont fait un benchmark rapide le samedi et ont célébré les résultats. Les chiffres semblaient héroïques—surtout sur une pool vide. Ils ont supposé que «SSD neuf + ZFS» signifiait que la première semaine serait la plus facile.

Ils ont sauté l’initialisation parce que ce n’était pas dans le runbook, et parce que «nous ne voulons pas user les disques». Cette phrase semble toujours sensée jusqu’à ce que vous réalisiez que la charge écrira ces octets de toute façon—mais à des moments aléatoires, pendant les heures ouvrables, pendant que les clients regardent.

Lundi matin : pics de latence VM. Pas continus, pas prévisibles. Assez nets pour que certains services entrent en storm de retries. Tout le monde a d’abord cherché le réseau (parce que tout le monde cherche toujours le réseau en premier), puis l’ordonnancement de l’hyperviseur, puis la base de données. Les graphiques stockage montraient une utilisation moyenne bien en dessous du max, ce qui rendait le tout plus confus. Ce n’était pas un problème de débit.

Quand ils ont finalement corrélé les pics avec l’amplification d’écriture à l’intérieur des SSD—visible via les métriques de latence au niveau du périphérique—le pattern est devenu évident : les premières écritures allaient dans des blocs «faciles». À mesure que l’allocation se dispersait et que la maintenance interne du SSD démarrait, la latence en queue a bondi. Ils ont en quelque sorte fait «initialize en production», par rafales chaotiques.

Ils ont mis en pause les jobs à forte écriture, ont exécuté zpool initialize la nuit pendant une semaine, et les pics de latence se sont calmés. La leçon durable n’était pas «toujours initialiser». C’était : ne pas benchmarker sur du vide. Le vide est un environnement de démonstration, pas une charge réelle.

2) L’optimisation qui a mal tourné

Une autre organisation avait l’habitude d’«optimiser» tout. Ils ont lu que l’initialisation est des écritures séquentielles et ont supposé que ce serait inoffensif si c’était limité. Ils ont donc lancé initialize pendant les heures de bureau sur un cluster de stockage partagé, en espérant que l’ordonnancement I/O de fond le garderait poli.

Pour être prudents, ils ont aussi lancé un scrub «pour s’assurer que tout est sain». Sur le papier, cela ressemblait à de l’hygiène : initialize réchauffe, scrub vérifie, tout le monde dort bien. En réalité, ils ont empilé deux scans lourds qui rivalisent pour l’I/O et le cache, alors que l’I/O applicatif était déjà non triviale.

Le résultat a été un incident en mode ralenti. Rien de critique n’a échoué. Aucune alarme évidente. Mais les latences p99 ont doublé, puis triplé. Le SRE de garde n’a vu aucun coupable unique. Le CPU allait bien. Le réseau allait bien. La pool était «ONLINE». Les utilisateurs, pas du tout.

Le retour de bâton était subtil : la charge de fond combinée a fait passer plus de temps au système en queue et moins en travail utile. Pire, les applis ont réagi en augmentant le parallélisme et les retries, ce qui a créé plus d’I/O aléatoire et rendu les scans moins efficaces. Boucle de rétroaction classique.

Ils ont corrigé en devenant ennuyeux : ne jamais lancer initialize et scrub ensemble, et ne jamais supposer que «I/O de fond séquentielle» est automatiquement inoffensive. Ils ont aussi ajouté un panneau de dashboard simple : «Une pool exécute-t-elle un scan ?» Cela a empêché de futures «optimisations utiles».

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe fintech utilisait ZFS pour une plate-forme orientée logs. Leur culture était résolument peu romantique : tout avait un runbook, et chaque runbook comportait des «préchecks». Ce n’était pas par amour de la paperasserie. C’était parce qu’ils détestaient les surprises.

Lorsqu’ils ont déployé une nouvelle étagère de SSD, le runbook exigeait : enregistrer les ID de périphériques, confirmer l’uniformité des firmwares, baseliner zpool iostat, exécuter initialize pendant une fenêtre planifiée, et surveiller les logs kernel pour les resets. La fenêtre d’initialisation était longue et ennuyeuse. L’ingénieur de garde la parcourait comme on regarde de la peinture sécher, sauf que la peinture ne vous fait pas sonner votre téléphone.

À mi‑parcours, un disque a commencé à lancer des timeouts intermittents. Pas assez pour échouer immédiatement, mais assez pour apparaître dans dmesg et comme des pics de latence occasionnels dans iostat. Ils ont arrêté initialize, remplacé le disque, et redémarré. Le fournisseur a ensuite confirmé un problème de firmware affectant un sous‑lot.

Si ils n’avaient pas initialisé, ce disque aurait peut‑être traîné pendant des semaines jusqu’à ce qu’un pic de trafic le force en mode défaillance. La pratique «ennuyeuse» ne les a pas rendus plus rapides ; elle les a moins surpris. C’est la vraie monnaie.

Blague #2 : Le meilleur incident de stockage est celui que vous vivez seulement comme une invitation calendrier.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: “Initialize made my pool slow”

Cause racine : Initialize est une I/O d’écriture soutenue lourde et entre en compétition avec le trafic de premier plan ; votre système n’avait pas de marge IOPS.

Correction : Suspendez initialize pendant les pics (zpool initialize -s), planifiez hors‑pic, et établissez des baselines avant/après pour prouver la causalité.

2) Symptom: Progress stuck at a percentage, ETA keeps growing

Cause racine : Un périphérique timeoute ou le chemin I/O est instable ; ZFS réessaie ou attend des commandes lentes.

Correction : Vérifiez dmesg pour des resets/timeouts, lancez SMART, vérifiez câblage/firmware HBA, et envisagez d’isoler le disque suspect.

3) Symptom: One disk is pegged at 100% util; others are calm

Cause racine : Disque défectueux, problème de négociation de lien, ou un seul périphérique dans un vdev RAIDZ qui ralentit le groupe à cause d’une latence mauvaise.

Correction : Comparez le await et le débit par disque. Changez de slot/câble. Si le problème suit le disque, remplacez‑le. Si il reste avec le slot, réparez le chemin.

4) Symptom: Initialization finishes, but workload still has huge tail latency

Cause racine : Ce n’est pas un problème de comportement «disque neuf». Probablement la pool est trop pleine, mauvais layout de vdev, mismatch ashift, ou charge sync‑heavy sans SLOG approprié.

Correction : Vérifiez la capacité de la pool (zpool list), la fragmentation, et les réglages des datasets ; évaluez la redondance et ajoutez des vdevs ou redesign si nécessaire.

5) Symptom: Pool shows errors during initialize

Cause racine : L’initialisation expose du matériel marginal. C’est une bonne nouvelle livrée de manière rude.

Correction : Traitez‑le comme un événement pré‑panne : rassemblez les logs, remplacez le composant, et relancez initialize sur le média de remplacement.

6) Symptom: You ran initialize expecting it to “verify” the pool

Cause racine : Confusion avec scrub. Initialize écrit ; scrub vérifie les checksums existants.

Correction : Utilisez zpool scrub pour la validation d’intégrité. Utilisez initialize pour le préconditionnement. Ne les échangez pas.

7) Symptom: Performance got worse after enabling autotrim alongside initialize

Cause racine : Votre firmware/périphérique/chemin ne supporte pas la combinaison d’écritures soutenues et de TRIM, ou l’implémentation entraîne un travail de fond supplémentaire au mauvais moment.

Correction : N’introduisez pas deux grandes variables en même temps. Stabilisez d’abord : lancez initialize avec autotrim inchangé, puis évaluez autotrim séparément avec surveillance.

8) Symptom: You initialized a pool during resilver and now everything is on fire

Cause racine : Vous avez empilé deux opérations I/O intensives et sensibles à la latence. Le resilver doit se terminer ; la redondance est à risque.

Correction : Arrêtez initialize. Laissez resilver se terminer. Ensuite initialisez à un moment plus calme, éventuellement seulement le périphérique remplacé.

Checklists / plan étape par étape

Checklist A: New pool bring-up with initialization (production-minded)

1. Enregistrez l’environnement : version ZFS, kernel OS, modèle/firmware HBA. La cohérence vaut mieux que l’ingéniosité.
2. Construisez la pool avec des IDs de périphériques stables (WWN/ATA IDs). Ne comptez jamais sur /dev/sdX.
3. Vérifiez la topologie avec zpool status et confirmez que la redondance correspond à la charge.
4. Confirmez ashift en utilisant zdb -C. Si c’est faux, arrêtez et reconstruisez maintenant. Le vous du futur ne le corrigera pas.
5. Baselinez la performance avec zpool iostat et iostat -x au niveau disque sous faible charge.
6. Vérifiez les erreurs dans dmesg avant de commencer. Si le kernel se plaint déjà, l’initialisation transformera les plaintes en pannes.
7. Démarrez initialize et surveillez immédiatement la progression via zpool status.
8. Surveillez les métriques par disque pour les outliers. Un outlier est un problème matériel jusqu’à preuve du contraire.
9. Arrêtez en cas d’erreurs et enquêtez. Ne laissez pas «ce n’est que l’initialisation» normaliser des défaillances matérielles.
10. Après completion, refaites les baselines et enregistrez les nouveaux chiffres d’état stable. Cela deviendra votre référence «connue bonne».

Checklist B: After replacing a drive in an existing vdev

1. Laissez le resilver se terminer. Vérifiez que zpool status est propre.
2. Exécutez smartctl -a sur le nouveau disque et confirmez que le firmware correspond au standard de la flotte.
3. Initialisez seulement le nouveau périphérique (si supporté dans votre environnement) pour le préconditionner.
4. Surveillez dmesg pour les resets/timeouts ; ce sont souvent des problèmes de slot/chemin révélés par des écritures soutenues.
5. Documentez ce qui a changé (serial, slot, firmware). Quand le prochain incident arrivera, vous voudrez corréler.

Checklist C: Operating on a busy pool (don’t be a hero)

1. Décidez l’objectif : réduire les pics futurs de latence, ou valider la stabilité matérielle ? Si aucun des deux, ne le lancez pas.
2. Choisissez une fenêtre : trafic bas, faible activité batch.
3. Fixez les attentes : publiez que la charge d’écriture de fond augmentera, et que la latence peut s’élever.
4. Démarrez initialize et surveillez les dashboards p99 latence.
5. Ayez une condition d’arrêt : si la latence dépasse un seuil, suspendez initialize. Soyez discipliné.
6. Reprenez plus tard. La complétion est agréable ; l’impact contrôlé est mieux.

FAQ

1) Does zpool initialize erase data?

C’est conçu pour être sûr sur une pool en cours d’utilisation, mais il écrit sur la totalité du vdev. Traitez‑le comme une opération d’écriture de fond lourde, pas comme un effacement destructeur. Cela dit : ne le lancez pas sur une pool que vous ne pouvez pas vous permettre de stresser sans surveillance et plan de retour arrière.

2) Is initialize the same as “burn-in” testing drives?

Lié, mais pas identique. Le burn‑in inclut souvent des tests SMART longs, des motifs lecture/écriture, des cycles de température et la surveillance d’erreurs hors ZFS. Initialize est un préconditionnement intégré à ZFS. Faites les deux si la fiabilité vous importe.

3) Should I initialize HDD pools too?

Parfois. Les HDD n’ont pas de flash translation layer, mais le firmware moderne peut quand même se comporter différemment sur des régions intactes. Plus important : initialize est un bon moyen d’exposer des disques marginaux ou des liaisons défaillantes via des I/O soutenues. Si votre pool est déjà chargée et stable, le bénéfice peut ne pas justifier la charge.

4) How long does initialization take?

En gros : taille de la pool divisée par la bande passante d’écriture soutenue que vous pouvez allouer. La parité RAIDZ, les limites du contrôleur et les charges concurrentes comptent. Faites confiance à zpool status pour des estimations en direct, mais souvenez‑vous que l’ETA est une supposition sous contention.

5) Should I run scrub after initialize?

Pas automatiquement. Scrub vérifie les blocs existants et répare via la redondance. Après la création d’une nouvelle pool, un scrub n’est pas une mauvaise idée comme contrôle de bon sens, mais ne lancez pas scrub et initialize en même temps. Échelonnez‑les.

6) Does initialize help with future resilver times?

Pas directement. Le temps de resilver dépend des données allouées, des performances du vdev et de la charge système. Initialize peut révéler des disques/chemins faibles tôt et réduire les surprises de performance, ce qui aide indirectement votre capacité à survivre aux resilvers sans drame.

7) What if my workload is mostly reads—do I still need initialize?

Si vous êtes vraiment majoritairement en lecture et que vous ne remplirez pas la pool rapidement, l’initialisation a moins de valeur. Mais si vous tenez à des performances prévisibles lors d’écritures occasionnelles lourdes (rebuilds, jobs batch, rafales de logs), initialize peut encore valoir le coup.

8) Is zpool initialize a replacement for TRIM?

Non. Initialize écrit ; TRIM informe le périphérique des blocs libres. Ils adressent des mécanismes différents. Sur des pools SSD, vous voulez souvent les deux : initialize pour préconditionner, et TRIM (autotrim ou périodique) pour garder un état stable sain.

9) Can I throttle initialization?

ZFS n’offre pas un bouton universel «vitesse d’initialize» couvrant tous les environnements. En pratique, vous gérez l’impact en planifiant, en suspendant/reprenant, et en contrôlant la priorité I/O système (là où c’est supporté). Le meilleur throttling reste «ne pas le lancer à midi».

10) How do I know initialization succeeded?

zpool status indiquera que l’initialisation est terminée. Plus important : vous devriez observer : aucun nouvel erreur Périphérique, latence disque stable, et moins de «pics mystères» quand la pool commence à se remplir.

Conclusion : prochaines étapes qui ne vous mordront pas plus tard

Si vous construisez de nouvelles pools ZFS sur des médias modernes, traitez zpool initialize comme un exercice d’évacuation incendie : gênant, contrôlé, et largement préférable à la vraie situation d’urgence. Lancez‑le quand vous avez de la marge, mesurez avant et après, et considérez toute erreur comme un signal sérieux—pas du bruit.

Prochaines étapes pratiques :

• Prenez une pool non critique et ajoutez initialize au runbook de construction, avec des conditions d’arrêt explicites.
• Standardisez le nommage des périphériques (WWN/ATA IDs) et les baselines de firmware pour que les diagnostics ne se transforment pas en archéologie.
• Construisez un petit panneau de dashboard : scans ZFS en cours (scrub/resilver/initialize), latence par disque, et taux d’erreurs kernel.
• Prenez une décision de politique : quand lancer initialize (nouvelle pool, après remplacements, avant migrations), et quand ne pas le faire.

Les nouveaux disques essaieront toujours de vous impressionner. Votre travail est de les faire se comporter quand personne ne regarde.