ZFS RAIDZ3 : quand la triple parité vaut les disques

janvier 9, 2026 • février 3, 2026 • Lecture : 35 min • Views: 9

Cet article vous a aidé ?

RAIDZ3 est la « troisième ceinture » de ZFS : une parité triple au sein d’un vdev RAIDZ. Elle vous coûte l’équivalent d’un disque de capacité en plus comparé à RAIDZ2, et elle vous achète une marge de sécurité nettement plus large précisément quand vous en avez le plus besoin : pendant de longues reconstructions sur de grands disques, sous charge réelle, avec le genre d’erreurs de secteur latentes qui n’apparaissent que quand vous avez déjà une mauvaise journée.

Si vous n’avez jamais perdu un pool pendant une resilver, RAIDZ3 peut sembler excessif. Si vous l’avez perdue, RAIDZ3 ressemble à cette fois où la finance a approuvé une assurance qui paie vraiment. Cet article vise à aider à prendre cette décision sans dogme, avec des chiffres exploitables, et des commandes que vous pouvez lancer à 3 h du matin quand le pager est plus bruyant que votre confiance.

Ce qu’est réellement RAIDZ3 (et ce que ce n’est pas)

En termes ZFS, RAIDZ est un RAID à parité implémenté au niveau du vdev. Un vdev RAIDZ3 peut perdre n’importe quels trois disques dans ce vdev et continuer à servir les données. Il le fait en stockant trois blocs de parité indépendants pour chaque stripe RAIDZ (conceptuellement similaire à des variantes RAID-7/RAID-6, mais ZFS le fait avec une largeur de stripe variable et une sémantique copy-on-write).

Ce que c’est :

Protection par triple parité par vdev. Perdez trois disques dans le même vdev RAIDZ3, vous restez en ligne. Perdez-en quatre, vous restaurez vos sauvegardes et pratiquez l’humilité.
Conçu pour de longues fenêtres de reconstruction et des modes de panne réalistes : deuxième (et troisième) panne de disque pendant la resilver, et erreurs médias latentes révélées par des lectures complètes du disque.
Simple opérationnellement comparé à des agencements plus exotiques. L’astreinte dispose d’un ensemble familier de commandes et d’un comportement de panne attendu.

Ce que ce n’est pas :

Ce n’est pas un substitut aux sauvegardes. RAIDZ3 réduit la probabilité de perdre un pool à cause de pannes multiples ; il ne vous protège pas contre la suppression, les ransomwares, les bugs applicatifs ou le classique « je pensais être sur staging ».
Ce n’est pas une panacée performance. Il peut être rapide pour les lectures/écritures séquentielles, mais les petits writes aléatoires paient une taxe de parité. La taxe de parité n’est pas théorique ; c’est le bruit des SLO de latence qui toussent.
Ce n’est pas « installer et oublier ». Vous devez toujours faire des scrubs, surveiller SMART, réaliser du burn-in et suivre des procédures de remplacement sensées.

Une blague, parce que les gens du stockage méritent aussi de la joie : RAIDZ3, c’est comme porter un casque sur une piste cyclable — on vous trouve parano jusqu’au jour où vous ne l’êtes pas.

Faits et historique qui comptent

Voici quelques points de contexte courts et concrets qui influencent réellement comment vous planifiez un pool RAIDZ3 :

ZFS a été conçu autour de sommes de contrôle de bout en bout (données + métadonnées), rendant la corruption silencieuse détectable et réparable quand la redondance existe.
RAIDZ a été créé pour éviter le « write hole » fréquent dans les contrôleurs RAID5/6 classiques lors d’une perte de puissance, en utilisant la sémantique transactionnelle copy-on-write.
Les capacités de disques ont augmenté plus vite que les IOPS depuis deux décennies. Votre fenêtre de reconstruction est en grande partie limitée par l’I/O, pas par votre volonté.
Les URE existent même lorsque les vendeurs n’aiment pas en parler. Sur les gros disques, la probabilité de rencontrer un secteur illisible lors d’une lecture complète n’est pas de la fantaisie ; c’est de l’arithmétique.
Les scrubs sont devenus opérationnellement « obligatoires » dans la culture ZFS parce qu’ils font remonter les erreurs latentes avant qu’une resilver vous force à tout relire au pire moment.
Advanced Format (4K) a changé le coût du mauvais alignement. Un ashift mal choisi peut transformer « ok » en « pourquoi c’est si lent ?» pour toujours.
Les disques SMR sont entrés dans le mainstream et ont remis le comportement de rebuild en critère d’achat. Une resilver qui prend une éternité n’est pas une resilver ; c’est une répétition d’indisponibilité prolongée.
Les entreprises ont adopté les « domaines de panne » (rack, shelf, expander, HBA) et ont arrêté de considérer la « panne de disque » comme un événement isolé. La triple parité traite en partie des pannes corrélées.

Pourquoi existe la triple parité : des maths de panne qu’on ressent

On présente parfois RAIDZ3 comme « pour les gens qui ne font pas confiance aux disques ». Ce n’est pas tout à fait ça. RAIDZ3 est pour ceux qui comprennent que le facteur ennemi, c’est le temps.

Le pool est le plus sûr juste après qu’un scrub soit terminé et que tous les disques soient sains. Le pool est le plus vulnérable pendant une resilver, quand :

Chaque disque est fortement lu (ou du moins plus que d’habitude), moment où les disques marginaux montrent leur vraie personnalité.
Vous êtes en mode dégradé — ce qui signifie que votre budget de redondance est déjà dépensé.
Vous servez souvent la charge de production, donc les pics de latence apparaissent, les files s’allongent, et « I/O de fond » devient « douleur au premier plan ».

Avec RAIDZ1, une seconde panne pendant la resilver tue le vdev. Avec RAIDZ2, une troisième panne peut le faire. Avec RAIDZ3, vous pouvez survivre à cette troisième panne et garder le pool en vie assez longtemps pour remplacer le matériel sans faire la fête de la restauration à minuit.

Mais le vrai moteur n’est pas juste « un autre disque tombe en panne ». C’est « quelque chose devient illisible au moment où nous devons le lire ». ZFS est très bon pour détecter les mauvaises données. La redondance est ce qui transforme « détecter » en « réparer ». La triple parité vous donne plus de marge pour que cette réparation réussisse lorsque la resilver lit tout.

Les vrais compromis : capacité, performances, coût opérationnel

Capacité : le coût évident

Dans un vdev RAIDZ3 unique avec N disques de taille égale, la capacité utilisable vaut approximativement (N − 3) disques (moins un peu pour les métadonnées ZFS et l’espace réservé). Cela signifie :

8 disques en RAIDZ3 : utilisable ≈ 5 disques
12 disques en RAIDZ3 : utilisable ≈ 9 disques
16 disques en RAIDZ3 : utilisable ≈ 13 disques

RAIDZ3 devient plus facile à justifier à mesure que la largeur du vdev augmente — parce que l’overhead de parité devient une fraction plus petite du total. Le piège : des vdevs RAIDZ plus larges allongent le temps de reconstruction et peuvent augmenter le rayon d’impact des problèmes corrélés si votre baie/chemin HBA est un seul domaine de panne. L’ingénierie n’est jamais un repas gratuit ; c’est plutôt un buffet où tout a du sodium caché.

Performances : taxe de parité, mais pas uniforme

La charge de travail importe plus que le niveau de parité. RAIDZ3 tend à être :

Excellent en lectures séquentielles (beaucoup de plateaux contribuent).
Bon en écritures séquentielles quand les enregistrements sont bien alignés et que vous n’avez pas de comportement sync pathologique.
Pas génial en petits writes aléatoires, car un RAID à parité nécessite de lire/modifier/écrire des stripes sauf si vous faites des full-stripe writes.

La triple parité peut augmenter un peu la charge CPU (calculs de parité), mais sur les systèmes modernes les contraintes dominantes sont habituellement les disques, la profondeur de file et l’amplification d’écriture — pas les XORs. Cela dit, ne construisez pas un pool RAIDZ3 sur un CPU sous-dimensionné puis ne soyez pas surpris quand checksums et compression entrent en compétition avec la parité à haut débit.

Coût opérationnel : la partie que personne ne budgète

RAIDZ3 change votre façon d’opérer parce qu’il change ce que signifie « risque acceptable ». En pratique il permet de :

Resilveriser pendant les heures ouvrées sans retenir son souffle aussi fort.
Utiliser des disques de plus grande capacité sans prétendre que les rebuilds durent encore 6 heures comme en 2012.
Exécuter des vdevs plus larges sans vivre dans la peur constante d’une troisième panne.

Mais il peut aussi pousser les équipes à la négligence : différer les scrubs, ignorer les alertes SMART, ou fonctionner trop proche de la totalité parce que « nous avons RAIDZ3 ». C’est ainsi que des designs robustes deviennent fragiles en production : pas parce que les maths étaient fausses, mais parce que les humains se sont relâchés.

Quand RAIDZ3 vaut les disques

RAIDZ3 est une bonne idée quand le coût d’une indisponibilité ou d’une restauration est élevé, et que la probabilité de « problèmes multiples pendant la reconstruction » est non négligeable. Voici des situations où je l’ai vu être le bon choix :

1) Très grands disques et longues fenêtres de resilver

Si vos resilvers prennent des jours, pas des heures, votre fenêtre d’exposition est suffisamment longue pour que « deux choses tournent mal » cesse d’être un événement rare. RAIDZ3 achète essentiellement une marge temporelle plus large.

2) Référentiels d’archivage ou de sauvegarde à haute capacité

Ironiquement, le stockage de sauvegarde a souvent besoin de plus de redondance que le stockage primaire. Pourquoi ? Parce que les systèmes de sauvegarde sont souvent martelés pendant les restaurations — exactement quand vous ne pouvez pas vous permettre que le pool s’effondre. De plus, les sauvegardes sont souvent construites avec de gros disques et des vdevs larges pour optimiser le $/TB, ce qui augmente le temps de reconstruction.

3) Pools avec risque de pannes corrélées connu

Exemples : étagère JBOD unique, expander unique, lot de disques du même batch, ou environnements avec vibration/thermal. RAIDZ3 ne résout pas les pannes corrélées, mais il vous donne de la marge pour les gérer sans transformer l’incident en catastrophe.

4) Environnements « hands-off » où le remplacement n’est pas immédiat

Sites distants, laboratoires, déploiements edge, ou tout endroit où un humain ne peut pas remplacer un disque en une heure. Si votre temps moyen pour remplacement se mesure en jours, la parité coûte moins cher que la réalité opérationnelle.

5) Objectifs de durabilité dictés par la conformité

Si vous avez des exigences internes comme « deux pannes concurrentes plus une erreur latente ne doivent pas provoquer de perte de données », RAIDZ3 est l’une des façons les plus simples d’y parvenir sans construire des schémas complexes de réplication multi-pools (que vous pouvez néanmoins mettre en place, mais au moins le pool local n’est pas à une mauvaise semaine d’une restauration).

Quand RAIDZ3 est la mauvaise réponse

La triple parité n’est pas un badge d’honneur. C’est un compromis. Évitez RAIDZ3 quand :

Vous avez besoin d’IOPS d’écriture aléatoires petits plus que d’efficacité de capacité

Bases de données, stockage VM et systèmes sensibles à la latence veulent généralement des mirrors (et parfois des vdevs spécialisés) plutôt que des RAIDZ larges. RAIDZ3 fonctionnera, mais sera souvent l’option la plus lente acceptable et parfois pas acceptable.

Vous pouvez réduire votre risque mieux avec la réplication

Si vous disposez déjà d’une réplication rapide et testée vers un autre système et que vous pouvez tolérer la perte d’un pool sans perdre de données, dépenser trois disques pour la parité peut valoir moins que les utiliser pour un second pool ou une cible de réplica. La phrase clé est « testée ». Une réplication non testée est une histoire du soir, pas un plan de reprise.

Vous êtes tenté de construire un seul vdev massif parce que RAIDZ3 rassure

Un très grand vdev peut être correct, mais il concentre le risque dans un seul domaine de panne. RAIDZ3 le rend plus survivable, pas invincible. Si vous construisez « le pool unique pour tous », demandez-vous si plusieurs vdevs ou plusieurs pools avec réplication correspondent mieux à votre modèle de panne.

Vdev width, ashift, recordsize : décisions de layout qui décident des résultats

Largeur du vdev : 8–16 disques, là où les débats deviennent sérieux

RAIDZ3 apparaît souvent avec des largeurs comme 10, 11, 12, 14, 16 disques. Des vdevs plus larges signifieront :

Plus de capacité utilisable par disque de parité (la fraction d’overhead de parité baisse).
Potentiel de débit séquentiel plus élevé (plus de plateaux participent).
Resilvers et scrubs plus longs (plus de données à lire, plus de disques impliqués).

Une heuristique pratique : si vous choisissez RAIDZ3, vous signalez déjà que le risque de resilver compte. Ne choisissez pas ensuite une largeur extrême qui rendra les resilvers insupportablement longs à moins d’avoir une raison opérationnelle solide (et une story de monitoring).

ashift : réglez-le correctement une fois, ou regretez-le pour toujours

ashift contrôle l’alignement secteur du pool. Les disques modernes sont effectivement en secteurs 4K même s’ils font semblant du contraire. La plupart des pools en production devraient être ashift=12 (4K). Certains environnements utilisent des dispositifs 8K ou 16K, mais l’essentiel est : choisissez correctement selon votre matériel, et ne laissez pas ZFS deviner automatiquement sur du matériel mixte.

Vous ne pouvez pas changer ashift après création. Vous ne pouvez que migrer.

recordsize et volblocksize : adaptez au workload

Pour les datasets de fichiers, recordsize affecte comment ZFS segmente les données. Un recordsize plus grand aide les charges séquentielles et réduit l’overhead métadonnées. Pour les zvols (dispositifs bloc), volblocksize doit être choisi à la création et aligné sur l’application (souvent 8K–64K selon DB/VM).

Les pénalités de parité RAIDZ sont pires quand vous forcez des écritures partielle-stripe de façon répétée. Vous pouvez atténuer cela en :

Utilisant des tailles de record appropriées pour votre charge.
Activant la compression pour réduire les écritures physiques (souvent un gain net).
Évitant les écritures sync pathologiques sauf si vous avez conçu pour elles (SLOG, budget de latence).

Opérations pratiques : commandes, interprétations, et à quoi ressemble un état « bon »

Ci-dessous se trouvent des tâches pratiques que j’attends d’un SRE en astreinte ou d’un ingénieur stockage sur un pool RAIDZ3. Chaque commande ici est quelque chose que vous pouvez exécuter. Les interprétations sont la partie qui empêche le « j’ai lancé les commandes, et je suis toujours confus ».

Task 1: Confirm the pool layout (and verify it’s actually RAIDZ3)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:33 with 0 errors on Mon Dec 23 02:11:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz3-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d8  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d9  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3da  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3db  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3dc  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3dd  ONLINE       0     0     0

errors: No known data errors

Interpretation : Vous cherchez la ligne raidz3-0. Si elle indique raidz2-0 ou raidz-0, vous n’avez pas la triple parité, peu importe ce que dit le wiki. Notez aussi les identifiants de périphérique : utiliser wwn-* est une bonne pratique ; cela évite les surprises de renumérotation des périphériques.

Task 2: Show health at a glance (watch for silent degradation)

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,capacity,health
NAME  SIZE   ALLOC  FREE  FRAG  CAPACITY  HEALTH
tank  145T   92.1T  52.9T  21%  63%       ONLINE

Interpretation : La capacité et la fragmentation comptent. Les pools RAIDZ qui tournent à chaud (80–90% pleins) souffrent souvent d’inefficacité d’allocation et de falaises de performance. RAIDZ3 ne change pas cette physique. Si vous êtes au-dessus d’environ 80%, attendez-vous à des écritures plus heurtées et à des scrubs plus longs.

Task 3: Check ashift (alignment) on the vdev

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

Interpretation : ashift: 12 indique généralement un alignement 4K. Si vous voyez ashift: 9 sur des disques 4K modernes, vous payez peut-être une pénalité permanente. La corriger implique de reconstruire le pool et de migrer les données.

Task 4: Start a scrub (and confirm it’s progressing)

cr0x@server:~$ sudo zpool scrub tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 01:02:18 2025
        3.21T / 92.1T scanned at 1.10G/s, 1.02T / 92.1T issued at 350M/s, 78.90T total
        0B repaired, 1.11% done, 3 days 01:20:11 to go
config:
...

Interpretation : Faites attention au débit issued, pas seulement à scanned. Si issued est bas, ZFS est probablement bridée par la contention de charge, des erreurs de périphérique ou des disques lents. Une ETA de scrub de plusieurs jours est normale sur de grands pools, mais des variations soudaines du taux peuvent signaler un problème.

Task 5: Find which disks are throwing errors

cr0x@server:~$ zpool status -v tank
...
            wwn-0x5000c500a1b2c3d8  ONLINE       0     2     0
            wwn-0x5000c500a1b2c3dc  ONLINE       4     0     0
...

Interpretation : Des compteurs READ/WRITE/CKSUM non nuls ne sont pas « ok » simplement parce que le pool est ONLINE. Pour RAIDZ, quelques erreurs transitoires peuvent arriver (câbles, hic d’expander), mais des erreurs répétées sur un même disque sont un signe précoce. Corrélez avec SMART et les logs kernel avant de décider si c’est le média, le chemin ou le contrôleur.

Task 6: Correlate ZFS errors with kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i 'sd[a-z]|sas|ata|reset|abort|I/O error' | tail -n 30
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 CDB: Read(16) 88 00 00 00 00 00 1a 2b 3c 40 00 00 00 80 00 00
[Mon Dec 23 21:44:02 2025] blk_update_request: I/O error, dev sdl, sector 439041088

Interpretation : Les « soft errors » et resets peuvent indiquer un lien instable. Les erreurs média tendent à apparaître comme des échecs LBA constants sur le même disque. Si plusieurs disques sur le même canal HBA montrent des resets, suspectez le câblage, l’expander ou le firmware.

Task 7: Check SMART health on a suspect disk

cr0x@server:~$ sudo smartctl -a /dev/sdl | egrep -i 'Model|Serial|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
Model Family:     Seagate Exos
Device Model:     ST16000NM000J
Serial Number:    ZL0ABC12
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct     0
Current_Pending_Sector    3
Offline_Uncorrectable     3
UDMA_CRC_Error_Count      0

Interpretation : « PASSED » n’est pas un bulletin de santé limpide. Les secteurs pending et offline-uncorrectable sont des signaux rouges, surtout pendant un scrub/resilver. Si les erreurs CRC augmentent, suspectez le câblage/backplane. Si pending/offline sont non nuls et augmentent, prévoyez un remplacement.

Task 8: Replace a failed disk using stable identifiers

cr0x@server:~$ zpool status tank | grep -E 'DEGRADED|FAULTED|OFFLINE|UNAVAIL'
 state: DEGRADED

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

Interpretation : Utilisez les chemins /dev/disk/by-id (WWN) plutôt que /dev/sdX. Après avoir émis zpool replace, surveillez la progression du resilver. Si vous avez remplacé le mauvais disque, RAIDZ3 peut vous sauver — mais ne considérez pas cela comme une fonctionnalité.

Task 9: Monitor resilver and confirm it’s not silently stalling

cr0x@server:~$ watch -n 10 'zpool status tank | sed -n "1,25p"'
Every 10.0s: zpool status tank

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 03:18:11 2025
        12.4T scanned at 780M/s, 3.10T issued at 196M/s, 92.1T total
        3.09T resilvered, 3.37% done, 1 day 19:02:10 to go
...

Interpretation : Un resilver qui montre du progrès en scanned mais n’augmente guère issued peut signifier contention ou erreurs. Si l’ETA commence à s’allonger sans changement de charge, investiguez l’attente I/O, des disques lents, ou un périphérique qui reset en boucle.

Task 10: Identify top latency contributors at the block layer

cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server)   12/24/2025  _x86_64_  (32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.1  0.0    4.3     21.7     0.0    61.9

Device            r/s   w/s   rkB/s   wkB/s  await  svctm  %util
sda              1.2   12.3   44.1    981.2   8.9    0.9    15.2
sdl             84.0   10.1  9032.0   1048.0  94.7    1.2    99.8
sdm             79.2    9.8  8900.0   1002.0  11.1    1.1    86.7

Interpretation : %util proche de 100% avec un await élevé sur un disque unique (ici sdl) est un symptôme classique « un disque traîne le vdev ». Les performances RAIDZ sont limitées par le participant le plus lent lors des opérations de parité. Inspectez SMART et la stabilité du lien de ce disque.

Task 11: Check ZFS dataset properties that commonly affect RAIDZ behavior

cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync,logbias tank/data
NAME       PROPERTY     VALUE
tank/data  recordsize   1M
tank/data  compression  zstd
tank/data  atime        off
tank/data  sync         standard
tank/data  logbias      latency

Interpretation : Un recordsize de 1M peut être excellent pour des workloads média/sauvegarde. La compression aide souvent les RAID à parité en réduisant les écritures physiques. sync=standard est généralement correct ; forcer sync=always sans un SLOG conçu peut faire exploser la latence d’écriture.

Task 12: See real-time ZFS I/O behavior (and spot a parity-bound workload)

cr0x@server:~$ sudo zpool iostat -v tank 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        92.1T  52.9T    420   1200  1.8G   310M
  raidz3-0                  92.1T  52.9T    420   1200  1.8G   310M
    wwn-...c3d4                 -      -     42    118   180M   31.0M
    wwn-...c3d5                 -      -     41    120   176M   30.8M
    wwn-...c3d6                 -      -     43    117   182M   31.1M
    wwn-...c3d7                 -      -     40    121   171M   30.9M
    wwn-...c3d8                 -      -     38    125   160M   31.5M
    wwn-...c3d9                 -      -     44    119   186M   30.7M
    wwn-...c3da                 -      -     42    120   180M   31.0M
    wwn-...c3db                 -      -     43    118   183M   30.9M
    wwn-...c3dc                 -      -     44    121   185M   31.2M
    wwn-...c3dd                 -      -     43    121   182M   31.2M
--------------------------  -----  -----  -----  -----  -----  -----

Interpretation : Un débit par disque équilibré est ce que vous voulez. Si quelques disques montrent un débit beaucoup plus bas (ou une latence beaucoup plus élevée dans iostat -x), votre plainte « RAIDZ3 est lent » peut en réalité être « un disque est mauvais et le vdev attend poliment pour lui ».

Task 13: Verify that autotrim is doing what you think (for SSD vdevs)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Interpretation : Pour les pools SSD, autotrim aide typiquement à maintenir des performances en steady-state. Sur un HDD RAIDZ3 c’est sans objet, mais les pools mixtes existent et les gens font des choses surprenantes sous pression budgétaire.

Task 14: Check for “special vdev” dependency before you celebrate redundancy

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz3-0                   ONLINE       0     0     0
            ...
        special
          mirror-1                   ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8  ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T9  ONLINE       0     0     0

Interpretation : Si vous avez un special vdev, vous avez créé une nouvelle dépendance : sa perte peut rendre le pool inutilisable même si RAIDZ3 est intact. Mettez votre special vdev en miroir correctement, surveillez-le agressivement, et comprenez quelles métadonnées/classes vous y avez placées.

Task 15: Confirm you’re not one reboot away from “why didn’t it import?”

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 12345678901234567890
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz3-0  ONLINE
            ...

Interpretation : C’est un contrôle de sanity pendant les fenêtres de maintenance ou après des changements matériels. Si zpool import montre des périphériques manquants inattendus, corrigez le câblage/le pathing avant d’avoir besoin de redémarrer pour une mise à jour du kernel.

Playbook de diagnostic rapide (chasse au goulet)

Quand RAIDZ3 « est lent », vous avez besoin d’un chemin rapide vers la vérité. Voici l’ordre que j’utilise pour éviter de me perdre dans le folklore du tuning.

Step 1: Is it one bad disk or path?

Exécutez zpool status -v : cherchez un disque avec des erreurs, un état DEGRADED ou une activité resilver/scrub.
Exécutez iostat -x 5 : cherchez un périphérique avec un await bien plus élevé ou un %util saturé.
Vérifiez dmesg -T pour des resets/timeouts sur le même périphérique ou bus.

Décision : Si un seul disque est lent ou reset, arrêtez le tuning ZFS et commencez par réparer le matériel. RAIDZ est un sport d’équipe ; un joueur boiteux ruine le jeu.

Step 2: Is the pool busy with maintenance?

Vérifiez zpool status pour scrub/resilver.
Utilisez zpool iostat -v 5 pour voir si la bande passante est consommée par des lectures de fond.

Décision : Si une resilver tourne, votre plainte de performance peut être « nous reconstruisons un disque tout en servant la production ». Ce n’est pas un mystère ; c’est un choix. Envisagez de planifier scrubs et remplacements plus stratégiquement.

Step 3: Is it sync write behavior?

Vérifiez la propriété dataset : zfs get sync,logbias.
Confirmez si la charge émet réellement des sync writes (bases de données, NFS, stockage VM souvent le font).

Décision : Si les pics de latence coïncident avec des sync writes et que vous n’avez pas un SLOG bien conçu (ou que vous avez forcé sync=always), vous avez trouvé le coupable.

Step 4: Is it a recordsize/volblocksize mismatch causing partial-stripe churn?

Pour les fichiers : vérifiez recordsize et les tailles d’E/S du workload.
Pour les zvols : vérifiez volblocksize (ne peut pas être modifié après création sans recréation).

Décision : Si votre workload est des writes aléatoires de 8K dans un large RAIDZ3, l’overhead de parité dominera. Envisagez des mirrors, un vdev spécial, ou une refonte.

Step 5: Is the pool too full or too fragmented?

Vérifiez zpool list capacité et frag.
Contrôlez les quotas/réservations de dataset et si une condition « presque pleine » est masquée par des snapshots.

Décision : Si vous êtes au-dessus d’environ 80–85% utilisé, le « tuning » le plus efficace pourrait être d’ajouter de la capacité ou de réduire l’utilisation. Envisagez quotas, réservations et rétention de snapshots. « Tuner ZFS » est rarement la meilleure première réponse à « on manque de place ».

Trois mini-histoires du monde de l’entreprise

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait un nouveau référentiel de sauvegarde : gros disques, un large vdev RAIDZ2, et une diapositive joyeuse disant « redondance deux disques ». L’hypothèse — répétée jusqu’à devenir politique — était que RAIDZ2 signifiait « on peut perdre deux disques à tout moment et ça ira ». Cette phrase n’est vraie que si vous traitez le « temps » comme un point, pas comme un intervalle.

Le premier disque a lâché un mardi matin. Ticket ouvert, remplacement commandé, pas d’urgence réelle parce que « nous sommes encore protégés ». Le remplaçant arrive tard mercredi. Pendant la resilver, la performance baisse, et l’ingestion de sauvegarde commence à prendre du retard. Quelqu’un a vu le retard, a supposé un problème de tuning, et a throttlé la resilver pour « aider la production ». Maintenant le pool est dégradé plus longtemps — exactement ce qu’il ne faut pas faire.

Jeudi soir, un deuxième disque a émis quelques erreurs de lecture. ZFS a corrigé ce qu’il pouvait, mais les compteurs d’erreur continuaient d’augmenter. L’équipe se sentait toujours rassurée : « RAIDZ2, non ? » Vendredi matin, le deuxième disque est tombé offline. Ils étaient désormais sans redondance pendant une resilver encore en cours.

Puis le troisième événement est arrivé : une erreur latente sur un autre disque s’est manifestée sous des lectures full-stripe. Avec RAIDZ2 et deux disques déjà hors-jeu (un en panne, un en détresse), le pool n’avait pas assez de membres sains pour reconstruire le stripe. Le résultat n’a pas été un moment propre et dramatique « le pool est mort ». C’était pire : des métadonnées partielles sont devenues illisibles, des services échouaient de manière étrange, et le plan de restauration a dû être exécuté sous pression.

Après coup, la leçon n’a pas été « RAIDZ2 est mauvais ». La leçon a été que l’hypothèse était fausse. La redondance n’est pas un nombre statique ; c’est un budget que vous dépensez pendant les incidents. RAIDZ3 n’aurait pas empêché la première panne. Il aurait donné à l’équipe plus de temps pour être humaine sans payer cela en données.

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a tenté de tirer plus de TB exploitables de son matériel. Ils avaient prévu un pool RAIDZ3, mais trois disques de parité « faisaient chers ». Quelqu’un a proposé un compromis : utiliser RAIDZ2, garder la même largeur de vdev, et « compenser la sécurité » en lançant des scrubs plus souvent.

Sur le papier, c’était malin : les scrubs détectent les erreurs latentes tôt, donc vous réduisez la chance de tomber sur des UREs pendant une resilver. Le retour de bâton est venu des détails. Les scrubs ont été programmés pendant les heures de bureau parce que les nuits étaient réservées aux pipelines de données, et l’équipe ne voulait pas « concurrencer les batchs ». Les scrubs tournaient donc en servant aussi des charges interactives.

La latence a monté, quelqu’un s’est plaint, et la réponse a été prévisible : throttling des scrubs, puis annulation, puis finalement ignorer les alertes parce que « ça finit toujours par se terminer ». Pendant ce temps, le pool continuait de se remplir et l’amplification d’écriture augmentait discrètement. Des mois plus tard, quand un disque a lâché et que la resilver a commencé, le pool était chaud (forte utilisation), fragmenté, et n’avait pas eu de scrub propre depuis longtemps.

Pendant cette resilver, deux choses sont arrivées : le disque de remplacement était plus lent que les autres (pas défectueux, juste un modèle différent avec un comportement soutenu différent), et un autre disque a commencé à montrer des secteurs pending. RAIDZ2 a survécu, mais de justesse — et l’impact sur la performance est devenu un incident de production à part entière. Ils ont eu de la chance. La chance n’est pas un contrôle d’ingénierie.

La décision finale a été, ironiquement, plus coûteuse : ajouter de la capacité pour réduire le remplissage, rééquilibrer la planification des charges, et finalement migrer vers RAIDZ3 lors du prochain renouvellement. L’« optimisation » n’était pas mauvaise parce qu’elle cherchait l’efficacité. Elle était mauvaise parce qu’elle supposait que la discipline opérationnelle resterait parfaite au fil du temps, alors que l’équipe et la charge changeaient.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Mes histoires de fiabilité préférées sont douloureusement peu sexy. Une équipe exécutait un pool RAIDZ3 pour un grand pipeline média. Rien de spécial : scrubs périodiques, contrôles SMART, et règles strictes de burn-in et d’étiquetage des disques. Les règles étaient assez ennuyeuses pour que les nouveaux embauchés lèvent les yeux au ciel. Ces règles sont aussi la raison pour laquelle le pool a survécu à une semaine vraiment moche.

Ça a commencé par un disque qui a commencé à loguer des erreurs CRC. Au lieu de remplacer immédiatement le disque, l’astreinte a traité d’abord le problème comme un souci de path — parce qu’ils avaient déjà été brûlés par des remplacements inutiles. Ils ont reseaté un câble, déplacé le disque dans une autre baie, et surveillé les compteurs. Les erreurs se sont arrêtées. Ce disque est resté en service, et l’incident s’est terminé en une tâche de maintenance d’une heure, pas en pool dégradé.

Deux semaines plus tard, un vrai disque a flanché (offline, SMART moche, toute l’opéra tragique). Ils l’ont remplacé le jour même, parce que des spares étaient déjà sur site et la procédure était scriptée. La resilver a commencé, et pendant la resilver un autre disque a commencé à émettre un petit nombre d’erreurs de lecture. RAIDZ3 a hausser les épaules ; le pool est resté en ligne et réparable.

Voici ce qui les a sauvés : ils avaient un calendrier de scrubs et ils ne l’ont pas annulé « parce qu’on est occupés ». Le dernier scrub s’était terminé récemment et les erreurs latentes étaient rares. Donc quand ce deuxième disque a commencé à faire des siennes pendant la resilver, il n’apportait pas une longue traîne de secteurs illisibles dans le pire moment possible.

Le postmortem a été ennuyeux dans le bon sens : remplacer le disque défaillant, surveiller le disque instable, planifier un remplacement proactif, et passer à autre chose. Personne n’a été promu pour ses héroïsmes. Mais personne n’a été viré pour perte de données non plus. En production, l’ennuyeux est une fonctionnalité.

Erreurs courantes : symptômes et fixes

Cette section est pour quand vous héritez d’un pool construit par quelqu’un qui est depuis « passé à de nouvelles opportunités ».

Mistake 1: Building RAIDZ3, then creating a single-disk special vdev

Symptôme : Le pool est RAIDZ3 mais semble « fragile ». La défaillance d’un seul SSD menace tout le pool.

Pourquoi ça arrive : Le special vdev contient des métadonnées (et éventuellement des petits blocs). S’il n’est pas redondant, il devient un point unique de défaillance.

Fix : Mettez le special vdev en miroir (au minimum). Si vous l’avez déjà construit en un seul disque, migrez les données et reconstruisez ; ZFS ne rendra pas magiquement les points uniques sûrs.

Mistake 2: Assuming RAIDZ3 makes scrubs optional

Symptôme : La première resilver après des mois conduit à des erreurs de checksum inattendues, une reconstruction lente, ou des blocs irrécupérables.

Fix : Planifiez des scrubs à une fréquence adaptée à la taille des disques et à la charge, et faites de leur achèvement un SLO surveillé. Les scrubs ne sont pas une maintenance ; ce sont des détections précoces.

Mistake 3: Using /dev/sdX paths and then “mysteriously” replacing the wrong disk

Symptôme : La commande de remplacement cible le mauvais périphérique après reboot ou reorder du contrôleur.

Fix : Utilisez toujours des IDs stables : /dev/disk/by-id/wwn-*. Étiquetez physiquement les baies et vérifiez les numéros de série avant de tirer un disque.

Mistake 4: Forcing sync writes without a design (SLOG myths)

Symptôme : Pics de latence, effondrement du débit, surtout pour NFS/VM.

Fix : Gardez sync=standard sauf si vous avez une raison. Si vous avez besoin de performance sync, concevez un SLOG adapté (protection perte de puissance, miroir si requis par votre modèle de risque) et mesurez.

Mistake 5: Mixing SMR drives into a RAIDZ3 pool unknowingly

Symptôme : Resilver/scrub prend une éternité, le pool devient lent sous charge d’écriture, le débit soutenu s’effondre de façon imprévisible.

Fix : Vérifiez les modèles de disques ; évitez les DM-SMR pour les vdevs RAIDZ à moins de comprendre vraiment la charge et d’accepter le comportement de rebuild. Si vous en avez déjà, planifiez une migration.

Mistake 6: Running the pool too full, then blaming RAIDZ3 for being slow

Symptôme : La latence d’écriture devient spongieuse autour de 80–90% de capacité ; les scrubs ralentissent ; les allocations se fragmentent.

Fix : Ajoutez de la capacité ou réduisez l’utilisation. Envisagez quotas, réservations et rétention de snapshots. « Tuner ZFS » est rarement la meilleure première réponse à « on manque d’espace ».

Mistake 7: Choosing recordsize/volblocksize by vibes

Symptôme : L’overhead de parité domine ; les workloads d’écritures aléatoires souffrent ; CPU et disques tournent en rond.

Fix : Adaptez recordsize au workload. Pour les zvols, choisissez volblocksize soigneusement à la création, puis benchmarquez avec des tailles d’I/O réalistes.

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

Checklist de planification : décider si RAIDZ3 est justifié

Mesurez votre fenêtre de reconstruction aujourd’hui (la durée d’un scrub est un proxy ; la resilver sera similaire ou pire sous charge).
Définissez la réalité opérationnelle : à quelle vitesse pouvez-vous remplacer un disque (heures vs jours) ?
Identifiez les domaines de panne corrélés : même baie, même expander, même batch, même firmware.
Quantifiez la douleur de restauration : temps de restauration, impact métier, coût humain.
Choisissez la largeur du vdev intentionnellement, pas parce que « c’est le nombre de baies qu’on a ».
Décidez si des mirrors servent mieux la charge (surtout pour l’I/O aléatoire).

Checklist de build : créer un pool RAIDZ3 sensé

Exemple de création (ajustez les périphériques à votre environnement). Ce n’est pas une religion du copier-coller ; c’est un modèle.

cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz3 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d4 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d5 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d6 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d7 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d8 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d9 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3da \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3db \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3dc \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3dd

Interpretation : ashift explicite, IDs stables explicites. Si vous ne faites rien d’autre, faites au moins cela.

Checklist opérationnelle : garder RAIDZ3 fiable de manière ennuyeuse

Programmez des scrubs, et alertez sur scrubs manqués/échoués.
Surveillez les attributs SMART (pending/offline uncorrectable, CRC errors, reallocated sectors).
Gardez des spares froids ou des chemins de remplacement rapides qui correspondent à votre tolérance au risque.
Suivez le remplissage du pool et la croissance des snapshots comme une métrique de premier ordre (parce que c’en est une).
Testez votre procédure de remplacement quand vous êtes calme, pas quand vous êtes en dégradé.
Documentez le mapping des périphériques (baie-vers-WWN/serial) et mettez à jour après chaque échange.

Deuxième blague, parce qu’on l’a méritée : Le moyen le plus rapide d’apprendre ZFS est de sauter les scrubs — ZFS vous enseignera alors personnellement, avec des labs interactifs à 2 h du matin.

FAQ

1) RAIDZ3 est-il « plus sûr » que des mirrors ?

Ils sont sûrs de façons différentes. Les mirrors offrent de fortes IOPS aléatoires et des rebuilds rapides (copie depuis le côté miroir sain). RAIDZ3 offre une meilleure efficacité de capacité à haute redondance pour les vdevs larges et une meilleure tolérance aux pannes concurrentes dans un vdev. Pour bases de données/VM, les mirrors gagnent souvent opérationnellement ; pour le stockage séquentiel/backup/archive, RAIDZ3 convient souvent mieux.

2) Combien de disques doit avoir un vdev RAIDZ3 ?

Il n’y a pas un nombre universel, mais RAIDZ3 se justifie généralement dans des vdevs larges où le temps de rebuild et les pannes corrélées deviennent des risques réels. Pratiquement, 10–16 disques est courant. Trop étroit et vous payez une grosse fraction de parité ; trop large et les resilvers/scrubs s’allongent et le domaine de panne grandit.

3) RAIDZ3 réduit-il le risque de corruption de données ?

ZFS checksums détectent la corruption indépendamment du niveau de parité. La redondance détermine si ZFS peut réparer automatiquement. RAIDZ3 augmente la probabilité que ZFS puisse reconstruire les données correctes même quand plusieurs disques ont des problèmes pendant un scrub/resilver.

4) RAIDZ3 est-il plus lent que RAIDZ2 ?

Habituellement un peu, surtout pour les petits writes aléatoires à cause de la parité supplémentaire. Pour les workloads séquentiels la différence peut être modeste. En pratique, « plus lent » est souvent dominé par d’autres facteurs : un disque lent, la saturation du pool, le comportement des sync writes, ou un mauvais choix de recordsize.

5) Puis-je convertir RAIDZ2 en RAIDZ3 en place ?

Pas dans le sens « retourner un interrupteur ». ZFS permet d’ajouter des vdevs, remplacer des disques par des plus grands, et diverses expansions dans des implémentations récentes, mais changer le niveau de parité d’un vdev n’est pas une opération simple in-place en pratique de production. Prévoyez une migration si le niveau de parité est incorrect.

6) RAIDZ3 me sauvera-t-il de perdre un pool pendant une resilver ?

Il améliore significativement vos chances, surtout quand un deuxième/troisième disque échoue ou a des erreurs de lecture pendant la reconstruction. Il ne garantit pas la survie contre des pannes corrélées catastrophiques (effondrement d’un expander, mise à jour firmware erronée, erreur humaine retirant plusieurs disques, etc.). Sauvegardes et réplication restent indispensables.

7) Dois-je utiliser RAIDZ3 pour le stockage de VM ?

Parfois, mais soyez méfiant. Le stockage VM tend à être à I/O aléatoire élevé et sensible à la latence ; les mirrors offrent souvent de meilleures performances et une compréhension opérationnelle plus simple. Si vous devez utiliser RAIDZ3 pour des VMs, investissez dans un bon choix de block size, envisagez un vdev special pour métadonnées/petits blocs (mirrored !), et benchmarquez avec des workloads réels.

8) À quelle fréquence dois-je scrubber un pool RAIDZ3 ?

Assez souvent pour détecter les erreurs latentes avant qu’une panne disque force une lecture complète en condition dégradée. L’intervalle « idéal » dépend de la taille du pool, du comportement des disques et de la charge. Opérationnellement : choisissez un calendrier que vous respecterez, assurez-vous que les scrubs se terminent, et alertez quand ils ne le font pas.

9) La triple parité est-elle excessive si j’ai de la réplication ?

Pas nécessairement. La réplication aide pour la reprise de sinistre et les corruptions logiques, mais elle ne vous sauve pas toujours d’une indisponibilité ou d’une longue fenêtre de restauration quand un pool local échoue. RAIDZ3 peut faire la différence entre « remplacer un disque et continuer » et « restaurer 100+ TB pendant que l’entreprise regarde ». La réponse dépend de vos RTO/RPO et du degré de test réel de votre reprise.

10) Quel est le plus gros « piège » avec RAIDZ3 en pratique ?

Les gens lui font trop confiance et sous-investissent dans l’opérationnel : scrubs, monitoring, identifiants de périphérique corrects, et éviter des points uniques comme un special vdev non miroré. RAIDZ3 est robuste, mais ce n’est pas un substitut à la discipline.

Conclusion

RAIDZ3 n’est pas pour tout le monde. C’est une réponse spécifique à un problème moderne : gros disques, longues reconstructions, et modes de panne qui arrivent en grappes, pas en événements indépendants et propres. Si perdre un pool serait un incident limitant de carrière, et si vos fenêtres de reconstruction sont assez longues pour que « quelque chose d’autre peut se passer » soit réaliste, la triple parité vaut souvent les disques.

Les meilleurs déploiements RAIDZ3 que j’ai vus n’ont rien d’héroïque. Ils ont l’air ennuyeux : IDs de périphériques stables, ashift sensé, scrubs qui se terminent vraiment, alertes SMART que quelqu’un respecte, et procédures de remplacement qui ne dépendent pas du savoir tribal. RAIDZ3 vous donne une marge. C’est l’opération qui décide si vous dépensez cette marge sagement.