ZFS RAIDZ1 : le calcul de risque que la plupart des gens ne font jamais

janvier 15, 2026 • février 3, 2026 • Lecture : 29 min • Views: 11

Cet article vous a aidé ?

RAIDZ1 est l’équivalent stockage de conduire avec une roue de secours et de se persuader que c’est une cage de sécurité. Ça fonctionne — jusqu’au jour où vous en avez besoin sous stress, à grande vitesse, par mauvais temps, avec des passagers qui se fichent que « ça a passé le dernier test ».

La plupart des discussions sur RAIDZ1 s’arrêtent à « un disque peut tomber en panne ». C’est vrai, et aussi dangereusement incomplet. La vraie question est : quelle est la probabilité qu’un second problème survienne pendant que vous rebuild, et combien de temps êtes-vous exposé ? C’est le calcul que les gens ne font pas, parce qu’il force une décision : RAIDZ2, mirrors, disques plus petits, plus de spares, meilleur monitoring, remplacements plus rapides, ou acceptation du risque — consciemment, pas par défaut.

Ce que RAIDZ1 protège réellement (et ce qu’il ne protège pas)

RAIDZ1 est un RAID à parité simple dans ZFS : vous pouvez perdre un périphérique dans un vdev et continuer à fonctionner. Cette affirmation est vraie de la même manière que « votre parachute peut échouer une fois » est vraie — techniquement exacte, émotionnellement peu utile.

Ce pour quoi RAIDZ1 est efficace

Il protège contre une seule panne complète de périphérique à l’intérieur d’un vdev, à condition que les périphériques restants soient suffisamment lisibles pour reconstruire les données manquantes. En pratique, RAIDZ1 est le plus à l’aise quand :

les disques sont plus petits (moins de données à lire pendant le rebuild),
la charge IO est modérée,
vous avez des hot spares ou des mains rapides,
vous lancez des scrub régulièrement et remplacez les disques tôt.

Ce que RAIDZ1 ne protège pas

Il ne vous protège pas contre un second problème pendant le resilver. Ce second problème n’est pas toujours « un autre disque qui meurt ». Le plus souvent, c’est l’un de ceux-ci :

Unrecoverable read errors (URE) sur les disques restants pendant la lecture pour reconstruire.
Erreurs de secteur latentes qui n’apparaissent que lors d’une lecture complète du vdev.
Délais de remplacement (approvisionnement, approbations, le spare est dans une autre région).
Problèmes de contrôleur/HBA/câblage qui choisissent le pire moment pour se manifester.
Effondrement induit par la charge où la charge du resilver plus la production provoquent des timeouts et des défauts en cascade.

Une petite blague courte, parce que vous l’avez méritée : RAIDZ1, c’est comme une ceinture de sécurité faite d’espoir — correcte jusqu’à ce que vous en ayez vraiment besoin.

Le calcul de risque que la plupart des gens ne font jamais

Voici la vérité inconfortable : avec RAIDZ1, votre risque est dominé par ce qui se passe pendant la fenêtre de resilver. Donc le calcul n’est pas « probabilité qu’un disque tombe en panne », mais :

Probabilité qu’un disque tombe en panne × probabilité d’une autre panne/URE pendant le resilver × durée d’exposition du resilver × réalité opérationnelle (alertes, spares, charge, réponse du personnel).

Étape 1 : définir vos modes de défaillance

Pour un vdev RAIDZ1 de N disques :

Premier événement : un disque échoue (ou est faulted, ou commence à renvoyer des erreurs qu’on ne peut plus ignorer).
Second événement : un autre disque échoue avant que le resilver ne soit terminé, ou vous rencontrez des lectures irrécupérables sur les disques restants lors de la lecture des blocs nécessaires à la reconstruction.

Les discussions classiques sur les RAID s’obsèdent sur les taux URE indiqués sur les fiches techniques. Cela compte, mais dans ZFS vous avez aussi :

Vérification des checksums qui détectera la corruption,
auto-réparation si la redondance existe (elle n’existe pas en RAIDZ1 une fois que vous êtes dégradé),
copy-on-write qui change les schémas d’écriture et la fragmentation.

Étape 2 : calculer votre fenêtre d’exposition (durée du resilver)

Plus votre resilver dure longtemps, plus vous vivez sans parité. Si le resilver prend 6 heures, vous pouvez accepter RAIDZ1. S’il prend 6 jours, vous avez effectivement programmé une semaine de « s’il vous plaît, ne pas éternuer ».

Le temps de resilver n’est pas « taille du disque / vitesse séquentielle ». En production réelle il dépend de :

octets réellement alloués (ZFS resilver only allocated blocks, pas le disque entier, sauf si forcé),
fragmentation du pool,
charge concurrente,
layout du vdev et ashift,
recordsize et amplification IO,
reprises d’erreur et timeouts des périphériques.

Étape 3 : modéliser le risque URE / erreur latente en clair

Les fabricants de disques annoncent l’URE comme quelque chose du type 1 erreur par 10^14 bits (grand public) ou 10^15 bits (meilleur), parfois 10^16 sur le papier pour le matériel enterprise récent. Traduisez ça :

10^14 bits ≈ 12,5 TB lus par URE attendu
10^15 bits ≈ 125 TB lus par URE attendu

Pendant un rebuild dégradé sur RAIDZ1, vous pouvez devoir lire beaucoup de données sur les disques survivants. ZFS n’a pas de magie ici : si un secteur est illisible et que vous n’avez plus de redondance, vous pouvez perdre des données. Selon le bloc et les métadonnées impliqués, cela peut être un fichier, un dataset, ou dans le pire des cas un échec au niveau du pool.

Le piège : les gens multiplient « taux URE » par « taille du disque » et s’estiment satisfaits. Mais le bon chiffre est « combien de données doivent être lues sur les disques restants pour reconstruire ce qui manque », ce qui peut approcher la taille des données allouées du vdev, plus l’overhead des retries et des métadonnées.

Un cadrage pratique du risque qui change les décisions

Au lieu de prétendre pouvoir calculer précisément la probabilité d’échec, les équipes opérationnelles font mieux avec des seuils :

Si le resilver se termine habituellement en quelques heures, et que vous pouvez remplacer les disques immédiatement, RAIDZ1 peut être acceptable pour des pools non critiques.
Si le resilver prend souvent plusieurs jours, RAIDZ1 devient une décision métier que vous devez documenter comme tout autre acceptation de risque.
Si vous ne pouvez pas garantir un remplacement rapide, ou si vous avez une forte utilisation, RAIDZ1 est souvent une fausse économie.

La deuxième petite blague (on s’arrête là)

Acheter des disques plus gros pour « réduire le nombre de points de défaillance » est la façon dont on finit avec moins de disques et plus de défaillances.

Pourquoi les disques modernes changent tout

RAIDZ1 est né dans un monde où « disque large » signifiait des centaines de gigaoctets, pas des dizaines de téraoctets. À l’époque, les fenêtres de rebuild étaient plus courtes, et la probabilité de rencontrer une erreur de lecture pendant un rebuild était nettement plus faible simplement parce qu’on n’avait pas à lire autant de données.

La croissance de capacité a dépassé la vitesse de rebuild

La capacité a explosé ; le débit séquentiel a augmenté, mais pas au même rythme — et l’IO aléatoire n’est pas devenu bon marché magiquement. Entre-temps, le resilver n’est rarement de l’IO purement séquentielle. C’est souvent « lectures avec beaucoup de seeks + calcul de parité + parcours de métadonnées », surtout sur des pools occupés.

Les workloads sont devenus plus bruyants

Virtualisation, containers, pipelines CI et systèmes à journalisation intensive génèrent des patterns IO qui sont l’opposé du « propre ». ZFS peut encaisser beaucoup, mais un RAIDZ1 dégradé sous IO aléatoire mixte est l’endroit où vous découvrez la différence entre « ça marche dans un benchmark » et « ça marche à 2 h du matin un mardi ».

Les disques helium et SMR compliquent les hypothèses

Les disques modernes peuvent être excellents, mais ils sont aussi plus divers. Les disques SMR (shingled magnetic recording) en particulier peuvent transformer un resilver en une galère de plusieurs jours si vous êtes malchanceux ou mal informé. Même avec des disques CMR, le comportement du firmware sous conditions d’erreur peut conduire à de longs timeouts.

ZFS est résilient, mais pas miraculeux

ZFS vous donne des checksums de bout en bout et de l’auto-réparation — quand la redondance existe. En RAIDZ1 dégradé, vous avez temporairement troqué « auto-réparation » contre « s’il vous plaît lisez parfaitement ». C’est un bon compromis pour des fenêtres courtes. C’est un mauvais compromis pour des fenêtres longues.

Faits intéressants et contexte historique

Les débats sur le stockage sont plus vieux que la plupart des données que nous protégeons. Quelques points concrets qui influencent la perception actuelle de RAIDZ1 :

ZFS a été conçu chez Sun Microsystems avec l’objectif explicite de résoudre la corruption silencieuse des données via des checksums et le copy-on-write, pas seulement « garder les disques en marche ».
Les problèmes de write hole de RAID-5 (perte de courant au milieu d’une bande) ont longtemps été une préoccupation ; ZFS évite beaucoup de ces pièges avec une sémantique transactionnelle, mais la parité conserve un risque de rebuild.
« RAID n’est pas une sauvegarde » est devenu un cliché parce que trop d’organisations traitaient la parité comme récupération, pas disponibilité. Le cliché existe parce qu’il reste vrai.
Les taux URE sont devenus célèbres quand les disques multi-téraoctets ont rendu « lire l’ensemble du groupe pendant un rebuild » un événement normal plutôt qu’exceptionnel.
Les baies enterprise ont discrètement basculé vers des parités doubles par défaut à mesure que la taille des disques augmentait, même si le marketing parlait encore d’« efficacité ».
Les scrub ZFS sont un artefact culturel du stockage basé sur checksums : l’idée de vérifier périodiquement que l’univers est intact, et pas seulement d’attendre que la corruption vous surprenne.
L’alignement des secteurs 4K (ashift) est devenu non négociable à mesure que les disques sont passés des secteurs physiques 512B ; un mauvais alignement peut brûler silencieusement les performances et augmenter l’usure.
L’expansion RAIDZ n’était pas disponible pendant des années, ce qui poussait les opérateurs à planifier soigneusement la largeur des vdev ; aujourd’hui l’expansion existe dans certaines implémentations, mais ce n’est toujours pas « redimensionner sans conséquences ».
Les mirrors sont restés populaires dans les environnements à fort IO parce que les rebuilds sont plus simples et souvent plus rapides ; la parité gagne sur la capacité, les mirrors gagnent sur la tolérance opérationnelle.

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

1) Incident causé par une mauvaise hypothèse : « Dégradé, c’est ok, on remplacera la semaine prochaine »

Une entreprise de taille moyenne utilisait un pool ZFS supportant des artefacts de build internes et des templates VM. Pas orienté client, donc le stockage était traité comme un utilitaire : important, mais pas urgent. Le pool était un unique vdev RAIDZ1 de gros HDD, dimensionné pour la capacité. Il tournait à haute utilisation parce que « stockage inutilisé = budget gaspillé ».

Un disque a faulted un vendredi après-midi. Les alertes ont sonné, un ticket a été ouvert, et quelqu’un a écrit la note classique : « Pool dégradé mais fonctionnel ; remplacement planifié. » La pièce n’était pas en stock. Procurement a fait ce que procurement fait.

Pendant le week-end, le pool est resté occupé parce que les jobs CI s’en fichent du modèle de staffing. Lundi matin, un deuxième disque n’est pas tombé complètement — il a commencé à renvoyer des erreurs de lecture intermittentes. ZFS a essayé, mais en RAIDZ1 dégradé, des erreurs de lecture intermittentes peuvent être aussi mortelles qu’une panne nette, parce que le pool a besoin de lectures propres pour reconstruire les blocs manquants.

Le symptôme n’était pas spectaculaire au début : certains builds ont commencé à échouer de façon étrange. Quelques VM ont refusé de booter depuis des templates. Puis ZFS a reporté des erreurs permanentes. L’équipe a perdu un sous-ensemble d’artefacts et a dû reconstruire des templates à partir de sources plus anciennes. L’impact métier n’était pas existentiel, mais ce fut une semaine d’attention d’ingénierie coûteuse.

La mauvaise hypothèse n’était pas « les disques tombent en panne ». La mauvaise hypothèse était de penser qu’un pool RAIDZ1 dégradé est assez stable pour différer l’action. En réalité, dégradé est un état d’urgence dont la sévérité est proportionnelle au temps de resilver et à la latence de remplacement.

2) Optimisation qui se retourne contre vous : « Faisons des RAIDZ1 plus larges pour plus d’efficacité »

Une autre organisation — plus grande, plus procédurale — voulait réduire le nombre d’armoires. Quelqu’un a proposé moins de vdevs mais plus larges : de larges groupes RAIDZ1 pour maximiser la capacité utilisable. Sur le papier, c’était élégant : moins de vdevs, layout plus simple, moins d’overhead.

En production, deux problèmes sont apparus. D’abord, la fenêtre de resilver a gonflé. Les vdevs larges signifiaient plus de données totales dans le vdev, plus de métadonnées, et plus d’opportunités pour des périphériques lents de ralentir tout le groupe. Ensuite, la performance pendant le resilver s’est effondrée sous des workloads mixtes ; le pool restait en ligne, mais les services utilisateur ont subi des pics de latence ressemblant à des bugs applicatifs.

Le retour de bâton est arrivé quand un disque a été remplacé et que le resilver a duré des jours. Pendant ce temps, un autre disque du même vdev a commencé à logger un nombre élevé d’erreurs de lecture. Il n’est pas tombé complètement, mais les retries ont ralenti encore le resilver, étirant la fenêtre d’exposition. L’organisation a évité la perte totale, mais la réponse à incident a mobilisé plusieurs équipes et déclenché une refonte douloureuse de la capacité.

Ils ont appris une leçon qui n’apparaît jamais dans des maths de capacité simplistes : l’efficacité opérationnelle vaut mieux que l’efficacité brute en capacité. Le téraoctet le moins cher est celui qui ne plonge pas votre équipe d’astreinte dans une enquête d’une semaine.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : scrubs, spares et remplacement rapide

Une troisième entreprise utilisait ZFS pour une plateforme interne modérément critique : les bases de données avaient leur propre réplication, mais le pool ZFS restait important. Ils utilisaient RAIDZ2 pour la plupart des pools, mais avaient un pool RAIDZ1 pour des workloads éphémères. La différence n’était pas dans l’héroïsme ; c’était dans la discipline.

Ils lançaient des scrub selon un planning et lisaient réellement les rapports de scrub. Les données SMART étaient monitorées, et les disques avec une hausse des secteurs réalloués étaient remplacés tôt — avant une panne franche. Ils gardaient aussi des spares froids dans le même datacenter, étiquetés et testés.

Quand un disque est tombé, il a été remplacé en une heure, pas en une semaine. Le resilver a démarré immédiatement, et la charge a été temporairement limitée (mise en pause des jobs non essentiels) pour raccourcir la fenêtre de resilver. Le pool est resté peu de temps en état dégradé.

Cet incident n’est pas devenu une histoire de guerre parce qu’il avait été conçu pour être ennuyeux. En termes SRE, ils ont réduit le risque avec un processus prévisible : détection précoce, mains rapides, et limitation du rayon d’impact. Ce n’est pas excitant, mais c’est ce à quoi ressemble « fiabilité ».

Tâches pratiques : commandes, sorties et ce qu’elles signifient

Ci-dessous, des tâches pratiques et exécutables sur un système ZFS. Les commandes partent du principe d’OpenZFS sur un hôte Linux avec un pool nommé tank. Ajustez les noms pour votre environnement.

Tâche 1 : Identifier le layout du vdev et confirmer que vous êtes vraiment en RAIDZ1

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:

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

errors: No known data errors

Interprétation : Vous avez un seul vdev RAIDZ1 avec quatre disques. Un disque peut tomber. En mode dégradé, vous avez une marge de parité nulle.

Tâche 2 : Vérifier le taux d’occupation du pool (une haute utilisation aggrave tout)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME        USED  AVAIL  REFER  MOUNTPOINT
tank       38.2T  4.10T   192K  /tank
tank/vm    25.6T  4.10T  25.6T  /tank/vm
tank/logs  12.6T  4.10T  12.6T  /tank/logs

Interprétation : Vous êtes proche de 90%+ utilisé. Attendez-vous à des allocations plus lentes, plus de fragmentation, et des resilvers plus longs. Si vous utilisez RAIDZ1 aussi plein, vous vous exposez au drame.

Tâche 3 : Voir les scrub et resilver récents

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0

Interprétation : Scrub terminé sans erreurs. Bien. Si vous ne lancez jamais de scrub, la première fois que vous trouvez un mauvais secteur peut être pendant un resilver — moment où RAIDZ1 ne peut pas vous sauver.

Tâche 4 : Lancer un scrub du pool (et comprendre le coût)

cr0x@server:~$ sudo zpool scrub tank

Interprétation : Les scrub lisent et vérifient les données. Planifiez-les quand l’IO peut le tolérer. Si les scrub trouvent constamment des erreurs, ce n’est pas « ZFS qui chipote » ; c’est ZFS qui trouve ce qui serait autrement une corruption silencieuse.

Tâche 5 : Surveiller la progression du scrub/resilver

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 01:12:10 2025
        7.24T scanned at 1.21G/s, 3.89T issued at 664M/s, 38.2T total
        0B repaired, 10.18% done, 0 days 15:42:11 to go
config:

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

Interprétation : ZFS donne une ETA, mais traitez-la comme une prévision météo. Si la vitesse « issued » chute fortement pendant les heures de bureau, votre workload entre en contention avec l’IO du scrub.

Tâche 6 : Identifier les disques et les chemins persistants

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'ST16000NM001G|wwn' | head
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0004 -> ../../sde

Interprétation : Utilisez by-id ou les chemins wwn dans ZFS, pas /dev/sdX qui peuvent changer après un reboot.

Tâche 7 : Remplacer correctement un disque défaillant (ne devinez pas les noms)

cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009

Interprétation : Le premier argument est l’ancien membre (comme ZFS le connaît). Le second est le chemin du nouveau disque. Après cela, le resilver commence. Si vous remplacez le mauvais disque en RAIDZ1, vous pouvez transformer « dégradé » en « perdu ».

Tâche 8 : Confirmer que le resilver a démarré et surveiller les erreurs

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Dec 24 02:02:41 2025
        1.78T scanned at 412M/s, 612G issued at 141M/s, 25.6T total
        0B resilvered, 2.34% done, 2 days 01:15:09 to go
config:

        NAME                              STATE     READ WRITE CKSUM
        tank                              DEGRADED     0     0     0
          raidz1-0                        DEGRADED     0     0     0
            ata-ST16000NM001G-1           ONLINE       0     0     0
            ata-ST16000NM001G-2           ONLINE       0     0     0
            replacing-2                   DEGRADED     0     0     0
              wwn-0x5000c500abcd0003      FAULTED      0     0     0  too many errors
              wwn-0x5000c500beef0009      ONLINE       0     0     0  (resilvering)
            ata-ST16000NM001G-4           ONLINE       0     0     0

errors: No known data errors

Interprétation : L’ETA du resilver est de 2 jours. C’est votre fenêtre d’exposition. Si un autre disque commence à renvoyer des erreurs maintenant, vous pouvez perdre des données. C’est le moment de réduire la charge et de surveiller les alertes de près.

Tâche 9 : Vérifier les compteurs d’erreurs par disque et les timeouts

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

        NAME                                         STATE     READ WRITE CKSUM
        tank                                         DEGRADED     0     0     0
          raidz1-0                                   DEGRADED     0     0     0
            /dev/disk/by-id/wwn-0x5000c500abcd0001   ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500abcd0002   ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500beef0009   ONLINE       3     0     0  (resilvering)
            /dev/disk/by-id/wwn-0x5000c500abcd0004   ONLINE       0     0     0

Interprétation : Des READ non nuls sur un disque survivant pendant le resilver sont un signal d’alerte. Parfois c’est transitoire (câble/HBA), parfois c’est un disque qui meurt. Enquêtez immédiatement ; RAIDZ1 ne pardonne pas le délai.

Tâche 10 : Récupérer la santé SMART et le log d’erreurs (Linux)

cr0x@server:~$ sudo smartctl -a /dev/sdd | sed -n '1,40p'
smartctl 7.4 2023-08-01 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST16000NM001G
Serial Number:    ZR123ABC
LU WWN Device Id: 5 000c50 0abcd0003
Firmware Version: SN03
User Capacity:    16,000,900,169,728 bytes [16.0 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Interprétation : Si SMART dit FAILED, traitez-le comme « évacuer ce disque ». Certains disques tiennent des mois ; d’autres chutent rapidement. Votre fenêtre de rebuild n’est pas le moment pour débattre d’optimisme.

Tâche 11 : Voir les propriétés des datasets qui affectent résilver et performance

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,compression,atime,sync tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  sync         standard

Interprétation : lz4 aide souvent (moins d’IO physique). atime=off réduit le bruit d’écriture. Le recordsize influence les patterns IO ; les incompatibilités peuvent amplifier l’IO aléatoire sur RAIDZ.

Tâche 12 : Vérifier l’I/O et la latence du pool avec iostat

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        38.2T  4.10T    210   1200  92.1M   410M
  raidz1-0                  38.2T  4.10T    210   1200  92.1M   410M
    wwn-0x5000c500abcd0001      -      -     55    310  24.0M   110M
    wwn-0x5000c500abcd0002      -      -     48    295  21.2M   105M
    wwn-0x5000c500beef0009      -      -     60    300  25.1M   100M
    wwn-0x5000c500abcd0004      -      -     47    295  21.8M    95M
--------------------------  -----  -----  -----  -----  -----  -----

Interprétation : Cela montre la distribution sur les disques. Si un disque montre beaucoup moins de bande passante ou beaucoup plus d’opérations, il peut être lent, en train de retry, ou défaillant. Pendant le resilver, vous verrez souvent de l’asymétrie ; une asymétrie extrême est un indice.

Tâche 13 : Vérifier si vous faites des hypothèses dangereuses sur le write caching

cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
 write-caching =  1 (on)

Interprétation : Le write cache sur HDD est normal, mais sans protection contre la perte de puissance, il peut transformer un événement d’alimentation en catastrophe. ZFS atténue certains problèmes, mais le hardware ment sous stress. Si vous avez besoin de garanties strictes, concevez pour elles.

Tâche 14 : Vérifier ashift (alignement secteur) du pool

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
38:        vdev_tree:
57:            ashift: 12

Interprétation : ashift=12 signifie secteurs 4K. Si vous avez créé un pool avec ashift=9 sur des disques 4K, vous pouvez subir des chutes de performance et une amplification d’écriture. Le corriger signifie généralement reconstruire le pool.

Tâche 15 : Vérifier les erreurs de données après un événement effrayant

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 25.6T in 2 days 03:12:44 with 0 errors on Thu Dec 26 05:15:25 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-ST16000NM001G-1     ONLINE       0     0     0
            ata-ST16000NM001G-2     ONLINE       0     0     0
            ata-ST16000NM001G-NEW   ONLINE       0     0     0
            ata-ST16000NM001G-4     ONLINE       0     0     0

errors: No known data errors

Interprétation : « 0 errors » est ce que vous voulez voir. Si vous voyez « permanent errors », ne passez pas à autre chose — listez les fichiers impactés, évaluez le rayon d’impact, restaurez depuis la sauvegarde si nécessaire.

Playbook de diagnostic rapide (trouver le goulot en urgence)

Voici le playbook que j’utilise quand quelqu’un tag : « Resilver est lent » ou « le pool RAIDZ1 rame ». L’objectif n’est pas d’être poète de la performance ; c’est de trouver le facteur limitant en quelques minutes.

Premier point : confirmer l’état du pool et ce que fait ZFS

cr0x@server:~$ zpool status -v tank

Regardez : DEGRADED, resilver in progress, erreurs read/write/cksum par périphérique, et tout message « too many errors ».

Deuxième point : identifier si le goulot est un périphérique défaillant ou une contention générale

cr0x@server:~$ zpool iostat -v tank 1 10

Interprétation : Si un disque est dramatiquement plus lent ou montre des erreurs, vous avez probablement un problème de périphérique/câble/HBA. Si tous les disques sont occupés et le débit est bas, vous êtes peut-être dominé par de l’IO aléatoire ou l’overhead CPU de la parité sous charge.

Troisième point : vérifier la pression IO au niveau système et le queueing

cr0x@server:~$ iostat -x 1 10

Regardez : haut %util, haut await, grosses queues. Si la latence explose pendant le resilver, bridez les workloads ou ajustez les priorités — un RAIDZ1 dégradé n’est pas le moment pour « full send ».

Quatrième point : vérifier la pression mémoire évidente (thrash ARC) et la saturation CPU

cr0x@server:~$ free -h
cr0x@server:~$ top -b -n 1 | head -n 20

Interprétation : Si vous swappez, ZFS va souffrir. Si le CPU est saturé, la parité plus compression plus checksumming sous charge peut devenir le facteur limitant.

Cinquième point : confirmer que le « disque lent » ne négocie pas mal

cr0x@server:~$ sudo dmesg | grep -Ei 'ata|sas|reset|link|error|timeout' | tail -n 30

Interprétation : Les resets de lien, timeouts et aborts de commandes apparaissent souvent ici avant un fault complet. En RAIDZ1 dégradé, traitez cela comme une alarme incendie, pas une ambiance.

Sixième point : si c’est encore flou, mesurez workload réel vs resilver

cr0x@server:~$ sudo zpool iostat -r -v tank 1 5

Interprétation : La répartition par taille de requête peut révéler que vous êtes bloqué sur de petites lectures aléatoires (fragmentation, workloads VM) plutôt que sur du streaming.

Erreurs courantes avec symptômes spécifiques et correctifs

Erreur 1 : Traiter un RAIDZ1 dégradé comme « stable »

Symptômes : Un disque tombe, un ticket est ouvert, le remplacement est retardé ; des jours plus tard, un second disque montre des erreurs ; le resilver n’a même pas commencé ; des erreurs de données apparaissent lors du rebuild éventuel.

Correction : Définissez un SLA pour le remplacement (heures, pas jours). Gardez des spares testés. Automatisez le paging pour DEGRADED. Réduisez la charge immédiatement quand vous êtes dégradé.

Erreur 2 : Faire tourner des pools trop pleins

Symptômes : Les scrub/resilvers prennent beaucoup plus de temps à mesure que l’utilisation augmente ; pics de latence ; échecs d’allocation ; « tout est lent » sans coupable évident.

Correction : Faites de la capacity planning avec marge (pratiquement : restez bien en dessous du précipice). Si vous devez fonctionner à chaud, n’utilisez pas RAIDZ1 ; choisissez une redondance qui supporte le stress.

Erreur 3 : Pas de scrub (ou scrub ignoré)

Symptômes : Premier scrub depuis des mois trouve des checksum errors ; un resilver plus tard échoue avec permanent errors ; « mais le pool était ONLINE hier ».

Correction : Planifiez des scrub. Alertez sur les erreurs de scrub. Remplacez les disques qui montrent une tendance à la hausse des erreurs même s’ils sont « toujours online ».

Erreur 4 : Mélanger des types de disques sans y penser (surprises SMR)

Symptômes : La vitesse du resilver est correcte au début, puis s’effondre ; les disques montrent de longs temps de commande ; le rebuild prend des jours de plus que prévu.

Correction : Évitez SMR en RAIDZ à moins d’avoir validé explicitement le comportement de resilver. Standardisez les modèles et firmwares des disques dans un vdev.

Erreur 5 : Utiliser des noms de périphériques instables

Symptômes : Après reboot, ZFS importe avec un mappage /dev/sdX différent ; l’opérateur remplace « sdc » mais ce n’est pas le disque voulu ; le pool empire.

Correction : Construisez et opérez toujours en utilisant /dev/disk/by-id ou des identifiants WWN. Vérifiez les numéros de série physiquement et via SMART.

Erreur 6 : Sur-optimiser recordsize/sync sans preuve workload

Symptômes : Des réglages « tune » semblent aider les benchmarks, mais en production vous observez plus de latence, plus de fragmentation, des resilvers plus lents.

Correction : Traitez le tuning comme une expérience avec rollback. Gardez les valeurs par défaut sauf si vous pouvez expliquer pourquoi votre workload est différent — et mesurez avant/après.

Erreur 7 : Croire que la parité remplace la sauvegarde

Symptômes : Le pool survit à une perte de disque, l’équipe se relâche ; plus tard ransomware/suppression accidentelle ; aucune copie propre n’existe.

Correction : Maintenez de vraies sauvegardes ou snapshots répliqués ailleurs. RAIDZ est disponibilité, pas récupération des erreurs humaines.

Listes de contrôle / plan étape par étape

Checklist A : Devriez-vous utiliser RAIDZ1 du tout ?

Classifiez les données. Si leur perte déclenche perte de revenu, breach contractuelle, ou récupération de plusieurs jours, n’utilisez pas RAIDZ1 par défaut.
Estimez la durée du resilver à partir de la réalité. Regardez votre dernière durée de scrub ; les resilvers sous charge ne seront pas plus rapides.
Confirmez la logistique de remplacement. Avez-vous un spare sur site ? Quelqu’un est-il autorisé à le remplacer immédiatement ?
Évaluez l’utilisation. Si vous fonctionnez à chaud, RAIDZ1 n’est pas le choix « efficace » ; c’est le choix « fragile ».
Décidez de votre fenêtre d’exposition tolérée. Si votre organisation ne peut pas tolérer des « quelques jours » d’exposition, n’utilisez pas RAIDZ1.

Checklist B : Lorsqu’un disque tombe en RAIDZ1 (minute par minute)

Confirmer que c’est un vrai problème matériel.
```
cr0x@server:~$ zpool status -v tank
cr0x@server:~$ sudo dmesg | tail -n 80
```
Décision : Si vous voyez des timeouts/resets, vérifiez câblage/HBA aussi — remplacer un bon disque ne réparera pas un lien défaillant.
Réduire la charge. Pausez les jobs batch, réduisez le churn VM, et arrêtez les grosses écritures si possible. L’objectif est de raccourcir le resilver et d’éviter d’autres erreurs induites par la charge.
Identifier le disque physique.
```
cr0x@server:~$ sudo smartctl -a /dev/disk/by-id/wwn-0x5000c500abcd0003 | grep -E 'Serial|SMART overall|Reallocated|Pending'
```
Décision : Faites correspondre les numéros de série avec les étiquettes du châssis. Ne faites pas confiance au folklore « slot 3 » sauf si vous l’avez vérifié.

Remplacer immédiatement en utilisant des IDs stables.

cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009

Surveiller le resilver et les erreurs en continu.
```
cr0x@server:~$ watch -n 10 'zpool status -v tank'
```
Décision : Si un autre disque commence à erreur, soyez prêt à escalader : remplacez les disques suspects, vérifiez le HBA, et envisagez de déplacer la charge hors du pool.
Après completion, lancer un scrub rapidement.
```
cr0x@server:~$ sudo zpool scrub tank
```
Décision : Vérifiez que le pool est propre et qu’aucune erreur permanente n’a été introduite.

Checklist C : Pratiques de « fiabilité ennuyeuse » qui rendent RAIDZ1 moins effrayant

Planning de scrub aligné sur la charge métier et la taille du pool ; alertez sur tout octet réparé ou checksum error.
Monitoring SMART avec seuils pour secteurs réalloués/pending et logs d’erreurs.
Spare sur site burn-in et étiquetés.
Runbook de remplacement documenté incluant identification du périphérique et étapes de rollback.
Politique de marge (ne pas pousser les pools au précipice).
Tests de restauration depuis sauvegardes/snapshots. RAID n’est pas votre plan de récupération.

FAQ

1) RAIDZ1 est-il « dangereux » ?

Pas intrinsèquement. Il est moins indulgent. Si vous pouvez garder les fenêtres de resilver courtes et les remplacements rapides, il peut être raisonnable pour des données non critiques. Si votre resilver se mesure en jours, RAIDZ1 est un risque que vous devriez traiter comme toute autre exposition opérationnelle à fort impact.

2) Pourquoi le risque RAIDZ1 augmente-t-il avec des disques plus grands ?

Parce que les rebuilds nécessitent de lire beaucoup de données sur les disques survivants, et des disques plus grands signifient plus de données à lire et plus de temps en mode dégradé. Plus de temps et plus de lectures augmentent la chance de rencontrer un second mode de défaillance (autre disque, erreurs de lecture, timeouts).

3) RAIDZ2 est-il toujours meilleur ?

Pour la fiabilité sous stress de rebuild, oui : la double parité vous donne une marge pendant un resilver. Mais « meilleur » implique des compromis : plus d’overhead de parité, des caractéristiques de performance différentes, et parfois une planification de capacité plus complexe. Pour beaucoup de pools de production, RAIDZ2 devient le défaut parce que les résultats opérationnels comptent plus que les TB utilisables purs.

4) Mirrors vs RAIDZ : lequel est plus sûr ?

Les mirrors sont souvent plus sûrs opérationnellement parce que les rebuilds (resilver) sont plus simples et souvent plus rapides, et la performance sous IO aléatoire est généralement meilleure. RAIDZ peut être excellent pour des workloads orientés capacité et débit. Si vous faites tourner des VM avec IO aléatoire sur des disques tournants, les mirrors se comportent souvent mieux en conditions de stress.

5) ZFS resilver lit-il tout le disque ?

Généralement il resilver seulement les blocs alloués (ce qui est bien), mais les pools fragmentés et certains scénarios peuvent malgré tout créer des rebuilds longs et IO-intensifs. Le conseil pratique reste : mesurez votre temps de resilver réel avec votre workload, pas en théorie.

6) Si je fais des scrub régulièrement, est-ce que cela élimine le risque de rebuild RAIDZ1 ?

Non, mais ça le réduit. Les scrub font ressortir les erreurs latentes tôt, quand vous avez encore de la parité. Cela signifie que vous pouvez corriger des problèmes avant d’être dégradé. Les scrub n’empêchent pas un second disque de tomber en panne pendant un resilver, et ils ne font pas disparaître les timeouts/câblage défectueux.

7) Quelle est la façon la plus simple de réduire le risque RAIDZ1 sans tout redesign ?

Raccourcir la fenêtre d’exposition et améliorer la réponse : garder des spares testés sur site, alerter bruyamment sur DEGRADED, et avoir une procédure de remplacement répétée. Gardez aussi de la marge ; les pools très pleins resilver plus lentement et sont plus fragiles sous charge.

8) Comment savoir si mon pool est à une erreur de la perte de données ?

Si c’est RAIDZ1 et que le pool est dégradé, vous y êtes déjà. Vérifiez avec zpool status -v. Toute erreur de lecture supplémentaire sur les disques restants pendant le resilver est une escalade sérieuse — enquêtez sur le hardware et envisagez de remplacer proactivement les disques douteux.

9) Puis-je « convertir » RAIDZ1 en RAIDZ2 en place ?

Dans beaucoup de déploiements, pas directement de la façon dont les gens l’espèrent. Certaines fonctionnalités d’expansion existent dans les écosystèmes OpenZFS modernes, mais changer le niveau de parité n’est généralement pas un simple commutateur. Le chemin opérationnel commun est de migrer les données vers un nouveau pool construit avec la topologie désirée.

10) Quel est un cas d’utilisation réaliste de RAIDZ1 aujourd’hui ?

Données non critiques, reproductibles ou bien répliquées ; environnements avec des mains et des spares rapides ; disques de plus petite capacité ; ou lorsque le pool est un cache plutôt que la source de vérité. Si le pool est votre seule copie de données importantes, RAIDZ1 devrait vous rendre mal à l’aise — et c’est un signal utile.

Conclusion : choisir RAIDZ1 en connaissance de cause

La réputation de RAIDZ1 oscille entre « totalement acceptable » et « à bannir », et les deux extrêmes manquent le point. La vraie histoire est la fenêtre de rebuild : combien de temps vous êtes dégradé, combien vous devez lire pour récupérer, et à quel point l’environnement est susceptible de produire un second mode de défaillance pendant que vous êtes exposé.

Si vous faites le calcul — vraiment le faire, avec vos durées de scrub réelles, votre utilisation réelle, votre processus de remplacement réel — RAIDZ1 cesse souvent d’être un choix par défaut et devient un choix délibéré. Parfois c’est encore le bon choix. Mais quand ce n’est pas le cas, vous le saurez avant que la sonnerie du pager ne vous l’apprenne à 3 h du matin.