ZFS vs mdadm : où mdraid l’emporte et où il échoue

Deux modèles mentaux : le stockage comme système de fichiers vs le stockage comme pile

Comparer ZFS à mdadm est un peu injuste parce qu’ils ne sont pas le même type d’objet.
ZFS est un système de stockage intégré : gestionnaire de volumes + RAID + système de fichiers + sommes de contrôle + snapshots + primitives de réplication.
mdadm est une couche RAID logicielle. Il crée un périphérique bloc. Il vous faut encore poser LVM et un système de fichiers (ext4, XFS, btrfs, etc.) par-dessus.

Cette différence change l’endroit où se situe la correction. Avec mdraid, l’intégrité des données se trouve principalement « ailleurs » :
votre système de fichiers, votre application, la vérification des sauvegardes et votre monitoring. Avec ZFS, l’intégrité est intégrée et volontaire :
chaque bloc est vérifié par checksum ; scrub est une opération de première classe ; les snapshots sont peu coûteux ; la réplication est conçue pour « expédier les changements, pas des copies complètes ».

Si vous lisez ceci parce que vous concevez un nouveau système : ne commencez pas par demander « lequel est plus rapide ».
Commencez par demander : quelles défaillances doivent survivre sans exploits humains ?
Puis demandez : quelles tâches opérationnelles doivent être sûres à 3h du matin ? La vitesse compte, mais la vitesse sans sûreté n’est qu’un moyen plus rapide d’obtenir des données incorrectes.

Faits historiques intéressants (court et utile)

• ZFS est sorti en 2005 (ère Solaris) en réaction aux systèmes de fichiers incapables de détecter de manière fiable la corruption silencieuse.
• mdraid précède les « piles de stockage » modernes ; il existe dans Linux depuis des décennies et reste le modèle mental par défaut pour beaucoup d’administrateurs : RAID, puis système de fichiers.
• Le « RAID5 write hole » n’est pas une légende ; c’est le risque réel d’une perte de courant pendant une mise à jour de parité laissant des stripes incohérents.
• RAIDZ de ZFS a été conçu pour éviter le write hole en utilisant la sémantique copy-on-write et des mises à jour transactionnelles.
• Les bitmaps d’intention d’écriture de mdraid existent précisément pour accélérer la resynchronisation après un arrêt non propre, au prix d’un surcoût d’écriture.
• L’adoption précoce de ZFS sur Linux a été freinée par des frictions de licence ; c’est pourquoi ZFS n’est pas « simplement dans le mainline » comme mdraid.
• ZFS a introduit des snapshots pratiques et adaptés à la production en tant qu’opérations peu coûteuses en métadonnées ; de nombreuses équipes ont construit des workflows de sauvegarde autour de cela avant que les « snapshots cloud » ne deviennent courants.
• Le RAID6 sur Linux a mûri parce que les disques sont devenus énormes ; les fenêtres de rebuild sont devenues suffisamment longues pour que la double parité cesse d’être « paranoïaque » et devienne « normale ».

Où mdraid gagne (et pourquoi)

1) C’est ennuyeux dans le meilleur sens : compatibilité maximale

mdraid est un périphérique bloc. C’est son super-pouvoir. Tout comprend les périphériques bloc : LVM, dm-crypt, XFS, ext4, outils de base de données, installateurs OS,
images cloud, environnements de récupération. Si vous voulez démarrer depuis un RAID1 dans un installateur de distribution basique sans modules supplémentaires, mdraid reste
la voie de moindre résistance.

Opérationnellement, cela signifie que vous pouvez déplacer l’array entre machines et le récupérer depuis presque n’importe quel ISO de secours Linux.
Des environnements de récupération ZFS existent, mais « disponible partout » est un vrai avantage pour mdraid.

2) Caractéristiques de performance prévisibles pour les charges simples

mdraid n’a pas d’ARC, ne fait pas de copy-on-write, ne fait pas de checksumming au niveau du système de fichiers.
Cela peut se traduire par une latence plus prévisible pour certains schémas d’écriture synchrones lorsqu’il est associé à un système de fichiers conservateur
et un ordonnanceur d’E/S ajusté.

Le RAID10 sur mdraid est particulièrement difficile à gâcher. Ce n’est pas toujours le plus efficace en espace, mais c’est indulgent.
Pour les charges sensibles à la latence (bases de données, files d’attente) où vous pouvez vous permettre des miroirs supplémentaires, RAID10 mdraid est une excellente base.

3) Plus facile à composer avec le chiffrement et les standards existants

Le chiffrement ZFS est bon, mais l’écosystème autour de dm-crypt/LUKS est massif. Si votre équipe conformité a déjà des procédures,
une gestion des clés et des playbooks d’incident basés sur LUKS, mdraid s’intègre proprement.

Exemple de pile qui fonctionne bien : mdraid (RAID10) → LUKS → XFS. C’est compréhensible, testable et relativement facile à récupérer.

4) Moins gourmand en RAM, moins d’éléments en mouvement en mémoire

ZFS aime la RAM. Pas parce qu’il est négligé, mais parce que l’ARC et le caching des métadonnées font partie de sa conception.
Si vous exécutez des nœuds à faible empreinte (edge, appliances, VM minimales avec disques directs), mdraid + ext4/XFS peut être le seul choix raisonnable.

Petite blague courte : mdraid est l’équivalent stockage d’un marteau-claw—peu glamour, bruyant, et toujours sur le camion quand vous en avez besoin.

Où mdraid perd (et comment cela fait mal)

1) La détection de la corruption silencieuse n’est pas son rôle

mdraid ne vérifie pas vos données de bout en bout. Si le disque renvoie des données erronées sans signaler d’erreur (oui, ça arrive),
mdraid livre volontiers ces données erronées à votre système de fichiers. Certains systèmes de fichiers peuvent détecter la corruption des métadonnées, mais les données utilisateur ne sont généralement pas vérifiées.

La conséquence pratique : vous pouvez avoir des lectures « réussies » de données corrompues, et ne l’apprendre que lorsqu’une application se plaint—ou pire, ne se plaint pas.
Votre atténuation devient « meilleures sauvegardes » et « vérifications régulières », ce qui est un plan, mais ce n’est pas un filet de sécurité intégré.

2) Le write hole de RAID5/6 et la laideur des partial-stripe

Le problème du write hole RAID5 : une perte de courant ou un crash pendant une mise à jour de parité peut laisser données/parité incohérents.
Des lectures ultérieures peuvent retourner de la corruption sans signal clair. Il existe des atténuations : UPS, journal d’écriture au-dessus, ou éviter la RAID parité pour les données critiques.
Mais le risque de base existe.

Pour les arrays à parité mdraid, vous devriez traiter un « arrêt non propre » comme un incident justifiant une vérification, pas comme une simple indifférence.
Le bitmap aide à accélérer la resynchronisation, mais il ne prouve pas magiquement la correction de chaque stripe.

3) Les rebuilds peuvent être brutaux et les réglages sont tranchants

La vitesse de rebuild est un compromis : aller vite et vous faites fondre la latence pour la production ; aller lent et vous prolongez la fenêtre de vulnérabilité.
mdraid vous donne des contrôles, mais ils sont plutôt globaux, faciles à oublier, et faciles à régler de façon à faire paraître la machine morte.

4) L’observabilité est fragmentée

Avec mdraid vous surveillez : état mdadm, SMART par disque, logs du système de fichiers, parfois LVM, parfois dm-crypt.
Rien de tout cela n’est impossible. Mais c’est un cockpit multi-panneaux, et les alarmes ne se recoupent pas toujours.

Où ZFS gagne (et quand c’est le choix évident)

1) Checksums de bout en bout et auto-réparation (lorsqu’il y a redondance)

ZFS calcule un checksum pour chaque bloc et vérifie à la lecture. Si la redondance existe (mirror, RAIDZ), il peut réparer en lisant une autre copie et en corrigeant.
Cela change la donne opérationnelle : la corruption devient un événement détecté et actionnable plutôt qu’un vague soupçon.

C’est la fonctionnalité qui fait passer ZFS de « système de fichiers » à « système d’intégrité ».
Si vous stockez quelque chose dont vous auriez honte de perdre—données clients, journaux d’audit, sauvegardes—cela compte.

2) Sémantique copy-on-write : snapshots plus sûrs, mises à jour de métadonnées plus sûres

ZFS écrit de nouveaux blocs puis bascule des pointeurs. Ce n’est pas juste une astuce ; c’est pourquoi les snapshots sont peu coûteux, et pourquoi certains problèmes de crash-consistence
sont moins excitants que dans les piles RAID parité.

Cela signifie aussi que la fragmentation et l’amplification d’écriture peuvent apparaître de manière surprenante si vous traitez ZFS comme ext4.
ZFS récompense la planification. Il punit les mises en page « YOLO, ship it » par une latence de queue imprévisible plus tard.

3) Snapshots et réplication comme opérations de première classe

Avec ZFS, « prendre un snapshot » et « répliquer incrémentalement » sont des opérations normales, pas des ajouts.
Si votre histoire RPO/RTO dépend de copies ponctuelles rapides et cohérentes, ZFS est souvent la réponse la plus propre.

4) Clarté opérationnelle : l’état du pool est un signal unique et significatif

zpool status vous donne une vue de santé réelle et significative : degraded, faulted, checksum errors, progrès du resilver.
Ce n’est pas parfait, mais c’est cohésif. mdraid a tendance à disperser la vérité entre plusieurs outils.

Deuxième petite blague courte : ZFS se souviendra de chaque erreur que vous avez faite avec recordsize—et contrairement à vos collègues, il vous montrera des graphes.

Une citation fiabilité (idée paraphrasée)

« Idée paraphrasée » de Werner Vogels : concevez des systèmes en vous attendant à des défaillances, et faites de la récupération un mode normal d’exploitation.

Patrons d’architecture qui fonctionnent réellement

Patron A : mdraid RAID10 pour les bases de données qui détestent les surprises

Si vous avez une base de données sensible à la latence (PostgreSQL, MySQL, Elasticsearch hot tier) et que vous pouvez vous permettre le mirroring,
mdraid RAID10 est une option très sensée. Associez-le à XFS ou ext4. Ajoutez un UPS. Surveillez SMART et l’état md.

Ce que vous n’obtenez pas : l’intégrité de bout en bout. Votre mitigation est la vérification des sauvegardes et des checksums hors ligne périodiques au niveau applicatif
(pour les jeux de données vraiment critiques).

Patron B : ZFS mirror ou RAIDZ2 pour « je tiens à la correction et à l’opérabilité »

Le mirror ZFS est le choix à faible drame : resilvers rapides, modes de défaillance simples, comportement prévisible.
RAIDZ2 est excellent pour la capacité avec sécurité, en particulier pour les gros disques où les fenêtres de rebuild sont longues.

Pour les VM, considérez des vdevs spéciaux, le réglage de recordsize, et des périphériques de log séparés seulement quand vous savez ce que cela fait.
ZFS récompense la simplicité : mirrors + bon monitoring + workflows de remplacement testés.

Patron C : mdraid + LUKS + XFS pour les environnements conformité-intensive

Si l’organisation standardise déjà sur les outils LUKS, les processus d’entiercement de clés et les procédures « break glass »,
mdraid s’intègre proprement. Ce n’est pas une victoire technique autant qu’opérationnelle.

Patron D : ZFS pour cibles de sauvegarde et stockage d’archivage

Les sauvegardes sont l’endroit où la corruption silencieuse vient prendre sa retraite. Le scrub de ZFS + checksums + snapshots en font une cible solide pour les sauvegardes,
même si votre stockage primaire n’est pas ZFS.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce ne sont pas des commandes « jouet ». Ce sont celles que vous exécutez quand quelque chose vous semble anormal et que vous devez décider si vous regardez un disque,
un contrôleur, une reconstruction, un problème de cache, ou une application qui fait quelque chose de regrettable.

Task 1: Confirm mdraid array health quickly

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5]
md0 : active raid10 sdb1[1] sda1[0] sdd1[3] sdc1[2]
      1953383488 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

Ce que cela signifie : [4/4] [UUUU] indique que les quatre membres sont actifs. L’absence de ligne de resync signifie qu’il n’est pas en reconstruction.
Décision : Si vous voyez [U_UU] ou une ligne resync/recovery, considérez cela comme dégradé et vérifiez quel disque est tombé.

Task 2: Get detailed mdraid member state

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Wed Nov  6 10:41:22 2024
        Raid Level : raid10
        Array Size : 1953383488 (1.82 TiB 2.00 TB)
     Used Dev Size : 976691744 (931.51 GiB 1000.20 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Thu Dec 26 01:12:09 2025
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

           Layout : near=2
       Chunk Size : 512K

Consistency Policy : resync

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync set-A   /dev/sda1
       1       8       17        1      active sync set-B   /dev/sdb1
       2       8       33        2      active sync set-A   /dev/sdc1
       3       8       49        3      active sync set-B   /dev/sdd1

Ce que cela signifie : State : clean est bon. « failed » ou « removed » signifie problème. Le layout et le chunk affectent la performance.
Décision : Si l’état n’est pas clean, lancez le workflow d’incident : identifiez le membre défaillant, vérifiez SMART, planifiez le remplacement et évaluez le risque de rebuild.

Task 3: Find which device is misbehaving (SMART triage)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep "Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall-health"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3

Ce que cela signifie : Les secteurs en attente et non correctibles sont un mauvais signe même si « PASSED » est affiché.
Décision : Planifiez le remplacement. Si l’array est dégradé, n’attendez pas. Si c’est un RAID parité, pensez à limiter les charges lourdes pendant le rebuild.

Task 4: Check ZFS pool health and error types

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 00:21:10 with 0 errors on Thu Dec 26 00:40:02 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Les compteurs READ/WRITE/CKSUM à 0, c’est le rêve. « scrub repaired » vous dit si ZFS a dû réparer quelque chose.
Décision : Si vous voyez des erreurs CKSUM sur un device, suspectez le câblage/le contrôleur ou le disque. Si « errors: Permanent errors », considérez une perte de données et restaurez depuis snapshot/réplica.

Task 5: Spot ZFS performance foot-guns in dataset properties

cr0x@server:~$ sudo zfs get compression,recordsize,atime,logbias,sync tank/db
NAME      PROPERTY     VALUE     SOURCE
tank/db   compression  lz4       local
tank/db   recordsize   128K      local
tank/db   atime        off       local
tank/db   logbias      latency   local
tank/db   sync         standard  local

Ce que cela signifie : recordsize impacte l’amplification d’E/S. sync affecte les sémantiques de durabilité.
Décision : Pour des bases de données avec pages 8K/16K, envisagez recordsize=16K ou 8K après test. Ne mettez pas sync=disabled sauf si vous aimez devoir expliquer une perte de données.

Task 6: Identify whether you’re bottlenecked on ZFS ARC

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
01:12:10   890   220     24    40   18   170   77    10    5   24.1G  28.0G
01:12:11   910   260     28    60   23   190   73    10    4   24.1G  28.0G
01:12:12   870   240     27    55   23   175   73    10    4   24.1G  28.0G

Ce que cela signifie : Un taux de miss autour de 25–30% peut être acceptable ou vous tuer, selon la charge.
Décision : Si ARC est limité bas par rapport à la RAM et que votre working set est plus grand, envisagez d’augmenter ARC max ou d’ajouter de la RAM. Si les misses sont élevés pendant des rafales, envisagez un special vdev séparé ou des disques plus rapides.

Task 7: Confirm mdraid rebuild is happening and estimate blast radius

cr0x@server:~$ watch -n 2 cat /proc/mdstat
Every 2.0s: cat /proc/mdstat

md0 : active raid6 sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0]
      5855592448 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/4] [UUU_U]
      [=>...................]  recovery =  7.3% (107822080/1463898112) finish=215.0min speed=105000K/sec

Ce que cela signifie : Dégradé ([5/4]) et en récupération à ~105 MB/s. L’ETA est approximative.
Décision : Si la latence en production est inacceptable, limitez la vitesse de rebuild ; si la fenêtre de risque est inacceptable, planifiez une maintenance ou évacuez temporairement la charge.

Task 8: Tune mdraid rebuild speed safely (temporary)

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Ce que cela signifie : la vitesse max de rebuild limitée à ~50 MB/s. Cela réduit la contention.
Décision : À utiliser quand vous devez garder une latence stable. Restaurez ensuite, et documentez le changement. Si vous oubliez, vous reconstruirez jusqu’à la prochaine année fiscale.

Task 9: Check filesystem-level health on mdraid (XFS example)

cr0x@server:~$ mount | grep /data
/dev/md0 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k)
cr0x@server:~$ sudo xfs_repair -n /dev/md0
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
No modify flag set, skipping filesystem flush and exiting.

Ce que cela signifie : -n est en lecture seule. S’il signale une corruption, planifiez une fenêtre pour une réparation réelle.
Décision : Si une corruption existe et que l’array a récemment subi un arrêt non propre, considérez-le comme probablement lié au write-hole sur les RAID parité. Vérifiez les sauvegardes avant réparation.

Task 10: Identify ZFS latency culprits live

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        2.10T  1.40T    220    980  18.2M  95.4M
  raidz2-0  2.10T  1.40T    220    980  18.2M  95.4M
    sda         -      -     45    210  3.6M  19.1M
    sdb         -      -     46    195  3.7M  18.4M
    sdc         -      -     40    205  3.4M  19.0M
    sdd         -      -     44    220  3.5M  20.1M
----------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Un IO par disque équilibré suggère qu’aucun disque unique ne bloque. Si un disque montre beaucoup moins de bande passante ou d’opérations, suspectez-le.
Décision : Si un disque individuel est à la traîne, corrélez avec SMART et le câblage. Si tous les disques sont occupés et que la latence est élevée, vous êtes lié par la charge ou sous-dimensionné.

Task 11: Replace a failed disk in mdraid (the safe sequence)

cr0x@server:~$ sudo mdadm --fail /dev/md0 /dev/sdc1
mdadm: set /dev/sdc1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm --remove /dev/md0 /dev/sdc1
mdadm: hot removed /dev/sdc1 from /dev/md0
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdf1
mdadm: added /dev/sdf1

Ce que cela signifie : L’array commencera la recovery après l’ajout. Surveillez /proc/mdstat.
Décision : Si le rebuild ne démarre pas, vérifiez le type de partition, un mismatch de version de superblock, ou que vous avez ajouté la bonne partition.

Task 12: Replace a failed disk in ZFS (and ensure it’s actually replacing)

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

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     FAULTED     12     0    45  too many errors
            sdd     ONLINE       0     0     0

cr0x@server:~$ sudo zpool replace tank sdc /dev/sde
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 01:14:02 2025
        148G scanned at 1.45G/s, 36.1G issued at 354M/s, 2.10T total
        36.1G resilvered, 1.68% done, 01:39:40 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              sdc     FAULTED     0     0     0
              sde     ONLINE       0     0     0  (resilvering)
            sdd     ONLINE       0     0     0

Ce que cela signifie : ZFS affiche un vdev « replacing » pendant le resilver. C’est votre confirmation que vous ne faites pas juste ajouter un disque au hasard.
Décision : Si la vitesse de resilver est faible, vérifiez l’activité du pool, les disques SMR ou les problèmes de contrôleur. Si les erreurs augmentent sur d’autres disques pendant le resilver, mettez en pause et réévaluez le risque.

Task 13: Verify mdraid superblocks when assembly is weird

cr0x@server:~$ sudo mdadm --examine /dev/sda1 | egrep "Array UUID|Raid Level|Device Role|State"
Array UUID : 1c2b7d1f:0e4c1c0a:4b2330c3:b51e1c66
Raid Level : raid10
Device Role : Active device 0
State : clean

Ce que cela signifie : Confirme que le membre appartient à l’array attendu.
Décision : Si les UUID diffèrent entre les membres, vous pourriez mélanger des disques de différents arrays. Arrêtez et cartographiez tout avant d’assembler quoi que ce soit.

Task 14: Detect ZFS “my pool is full and now everything is slow”

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  3.40T   120G    96K  /tank

Ce que cela signifie : 120G de libre sur un pool de plusieurs To peut être dangereusement faible selon la charge.
Décision : Si l’espace libre est inférieur à ~10–20% pour des pools occupés, planifiez un nettoyage immédiat ou une expansion. Les performances ZFS et le comportement de l’allocateur se dégradent quand le pool est serré.

Task 15: Check for mdraid write-intent bitmap usage

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "Intent Bitmap|Bitmap"
     Intent Bitmap : Internal

Ce que cela signifie : Le bitmap est activé ; la resync après un crash sera plus rapide (seulement les régions modifiées).
Décision : Pour les arrays parité sur des systèmes susceptibles de crasher ou de redémarrer, le bitmap vaut souvent le petit coût d’écriture. Pour des charges très écrites, mesurez l’impact.

Task 16: Confirm IO is the bottleneck (not CPU, not memory)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   22.10    0.00   66.34

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await  w/s     wkB/s   w_await  aqu-sz  %util
md0             120.0  18000.0     0.0    0.0     8.4  980.0  98000.0    34.2    18.7   98.0

Ce que cela signifie : Un %iowait élevé et un %util ~98% indiquent un stockage saturé. w_await ~34ms est pénible pour des applis sensibles à la latence.
Décision : Si c’est pendant un rebuild, limitez le rebuild ou évacuez la charge. Si c’est en production normale, vous avez besoin de plus de spindles, de SSD, d’un meilleur niveau RAID, ou de modifications de la charge.

Plan de diagnostic rapide

Quand le stockage devient « lent », votre premier travail est d’éviter de perdre du temps. Votre second travail est d’éviter d’empirer la situation.
Cet ordre est conçu pour identifier les goulots en minutes, pas en heures.

Premier : sommes-nous en reconstruction ou dégradés ?

• mdraid : cat /proc/mdstat et mdadm --detail /dev/mdX. Cherchez recovery, resync, [U_U].
• ZFS : zpool status. Cherchez DEGRADED, resilver, augmentation des compteurs READ/WRITE/CKSUM.

Si oui : attendez-vous à de la latence. Décidez de limiter le rebuild ou de planifier une fenêtre de maintenance. Ne discutez pas avec la physique.

Second : est-ce un seul disque, un bus, ou tout l’array ?

• iostat -xz 1 pour voir la saturation et les temps d’attente.
• zpool iostat -v 1 pour voir si un vdev/périphérique est à la traîne.
• smartctl -a sur les disques suspects ; regardez les secteurs en attente/non correctibles et les erreurs CRC (souvent du câblage).

Un disque défectueux peut tirer un array dans la misère bien avant d’« échouer ». C’est pourquoi le monitoring doit alerter sur la dégradation SMART, pas seulement sur les disques morts.

Troisième : confirmer le pattern de charge

• Écritures sync élevées ? Vérifiez les paramètres applicatifs, le comportement fsync, et sur ZFS vérifiez sync/logbias.
• Lectures aléatoires avec faible cache hit ? Vérifiez les stats ARC de ZFS ou la pression sur le cache de pages Linux.
• Petites écritures sur RAIDZ/RAID5 ? Attendez-vous à de l’amplification d’écriture et du surcoût de parité.

Quatrième : vérifiez les limites « ennuyeuses » qui causent de la douleur

• Pool ZFS trop plein (peu d’espace libre).
• Limites de vitesse de rebuild mdraid accidentellement basses/hautes.
• Erreurs de contrôleur dans dmesg (timeouts, resets).
• Partitions mal alignées ou tailles de secteurs étranges lors du mélange de disques.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: parity array returns corrupted files after power loss

Cause racine : Exposition au write hole RAID5/6 + arrêt non propre, plus absence de checksums de bout en bout.

Correction : Préférez RAID10 ou RAIDZ ZFS pour les données critiques. Si vous restez sur une parité mdraid : UPS + write-intent bitmap + pratiques d’arrêt cohérentes + outils de vérification.

2) Symptom: mdraid rebuild makes production unusably slow

Cause racine : Rebuild saturant l’I/O ; speed_limit_max trop élevé ; rebuild parité effectuant des lectures/écritures sur des full-stripes.

Correction : Throttle le rebuild (/proc/sys/dev/raid/speed_limit_max), planifiez des fenêtres de rebuild, et envisagez RAID10 pour les charges sensibles à la latence.

3) Symptom: ZFS pool is ONLINE but applications see random corruption

Cause racine : Souvent pas ZFS lui-même—plus communément la RAM défectueuse sur des systèmes sans ECC, ou un contrôleur instable mentant sur les écritures.

Correction : Lancez des tests mémoire, vérifiez les événements ECC, inspectez dmesg pour des resets de contrôleur. Sur ZFS, faites confiance aux erreurs checksum : si elles augmentent, le matériel est coupable jusqu’à preuve du contraire.

4) Symptom: ZFS write latency spikes after enabling snapshots for everything

Cause racine : Churn de snapshots + fragmentation + mismatch de small recordsize pour la charge, surtout sur des datasets VM très actifs.

Correction : Réduisez la fréquence/rétention des snapshots sur les datasets chauds, ajustez recordsize/volblocksize de manière appropriée, envisagez des pools séparés pour images VM vs fichiers généraux.

5) Symptom: mdraid array assembles but filesystems won’t mount cleanly

Cause racine : Le périphérique bloc sous-jacent est « OK », mais les métadonnées du système de fichiers ont subi un choc (arrêt non propre, erreurs matérielles).

Correction : Effectuez des vérifications de système de fichiers (xfs_repair / fsck) en mode maintenance ; confirmez les sauvegardes avant réparations qui pourraient supprimer des métadonnées.

6) Symptom: ZFS resilver takes forever compared to expectations

Cause racine : Le resilver lit seulement les blocs alloués (bien), mais peut être lent à cause de disques SMR, fragmentation du pool, I/O concurrent lourd, ou device lent.

Correction : Identifiez le device lent avec zpool iostat -v, évitez les SMR pour les vdevs, gardez de l’espace libre sain, planifiez les resilvers hors-peak.

7) Symptom: “We replaced a disk but the array still looks degraded”

Cause racine : Remplacé la mauvaise partition, mauvais nom de device, ou confusion replace/add ZFS ; dans mdraid, le disque n’a pas réellement été ajouté en tant que membre.

Correction : Pour mdraid, vérifiez avec mdadm --detail et contrôlez les rôles des membres. Pour ZFS, cherchez le vdev « replacing » dans zpool status et confirmez que le nouveau disque resilvere.

Trois mini-récits d’entreprise issus du terrain

Mini-story 1: The incident caused by a wrong assumption

Une société SaaS de taille moyenne utilisait mdraid RAID6 sous XFS pour un partage de fichiers. L’hypothèse était simple :
« RAID6 signifie que deux disques peuvent tomber, donc nous sommes en sécurité. »

La machine a subi un événement d’arrêt brutal. Elle a redémarré. L’array md s’est assemblé. /proc/mdstat disait que tout était clean.
Les utilisateurs ont commencé à se plaindre de fichiers corrompus « aléatoires ». Rien n’était suffisamment cohérent pour pointer un répertoire unique.

L’équipe a cherché des bugs applicatifs pendant une journée. Puis quelqu’un a exécuté des comparaisons de checksum contre le jeu de sauvegardes offsite et a trouvé des divergences sur des fichiers modifiés juste avant l’incident.
Aucun disque n’affichait d’erreur claire. SMART semblait « correct ». L’array disait la vérité de son point de vue : il ne savait pas que la relation parité/données était incohérente.

Cause racine : une fenêtre classique d’incohérence de parité pendant le crash—effectivement le write hole rendu visible. Les métadonnées XFS étaient majoritairement intactes,
donc les montages semblaient normaux. La corruption vivait dans les données utilisateurs où il n’y avait pas de checksums de bout en bout.

La correction n’a pas été astucieuse. Ils ont restauré les datasets affectés depuis les sauvegardes et changé de conception : ZFS pour le partage de fichiers avec scrubs et snapshots,
ou mdraid RAID10 pour les données chaudes impossibles à migrer immédiatement. Ils ont aussi commencé à traiter « arrêt non propre sur RAID parité » comme un incident réel.

Mini-story 2: The optimization that backfired

Une équipe liée à la finance utilisait ZFS pour du stockage VM et voulait plus d’IOPS. Quelqu’un a noté que « les écritures sync sont lentes » et a fait le mouvement tentant :
mettre sync=disabled sur le dataset VM.

Les benchmarks semblaient fantastiques. La latence a chuté. Les graphes se sont calmés. Le changement a été promu en « tuning standard » en silence.
Personne ne l’a documenté parce que, eh bien, « ça marche ».

Quelques semaines plus tard, un hyperviseur a redémarré de façon inattendue (pas un arrêt de courant—juste un kernel panic dû à un driver non lié).
Plusieurs VMs sont revenues avec des bases de données qui ne démarraient pas, ou pire, qui avaient perdu des transactions de façon subtile.
Le stockage était sain. Le pool était ONLINE. Le dommage était au niveau applicatif : des écritures confirmées qui n’avaient jamais atteint le stockage stable.

Le postmortem a été douloureux parce que ce n’était pas mystérieux. Le système était configuré pour mentir sur la durabilité.
Et les VMs lui faisaient confiance. Parce que c’est ce que font les ordinateurs.

Ils sont revenus à sync=standard, ont ajouté un SLOG approprié pour les charges nécessitant des écritures sync à faible latence, et ont mis à jour la gestion du changement :
tout paramètre affectant la durabilité nécessite une approbation de risque explicite. « Rapide » n’est pas une exigence business si « correct » est optionnel par accident.

Mini-story 3: The boring but correct practice that saved the day

Une équipe d’entreprise utilisait un mix : mdraid RAID10 pour les serveurs DB, ZFS pour les cibles de sauvegarde. Rien de révolutionnaire.
Ce qu’ils faisaient avoir était une pratique ennuyeuse : des « recovery drills » mensuels incluant le remplacement d’un disque en staging,
l’assemblage d’un array md depuis des disques cold, et la restauration d’un dataset ZFS depuis une réplication incrémentale.

Un vendredi, un nœud DB a commencé à logger des timeouts I/O intermittents. SMART a montré une augmentation des erreurs CRC sur un disque.
C’est souvent un câble ou un backplane défaillant, mais en RAID10 c’est toujours un signal « remplacer quelque chose ». Ils ont marqué le membre comme faulty,
l’ont retiré, remplacé le disque, et lancé le rebuild. Routine.

Pendant le rebuild, un second disque sur le même backplane a commencé à jeter des erreurs et est tombé. Pas complètement mort, mais instable.
Parce qu’ils surveillaient proactivement, l’on-call avait déjà le plan de secours, la séquence exacte de commandes, et les seuils « arrêter si X se produit ».

Ils ont ralenti la vitesse de rebuild, déplacé le trafic de lecture hors du nœud, et profité du temps pour remplacer le câble/le slot du backplane suspect.
L’array s’est stabilisé et la récupération s’est terminée sans perte de données. Pas de héros. Pas d’improvisation.

La note post-incident était presque ennuyeuse : « Suivi du runbook. » C’est tout le propos.
L’ennui est ce que vous voulez du stockage. L’excitation appartient aux démos produit, pas à votre couche bloc.

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

Choisir entre ZFS et mdraid (checklist de décision)

1. Si vous avez besoin d’intégrité de bout en bout (détecter + réparer la corruption) : choisissez ZFS.
2. Si vous avez besoin de portabilité maximale et de chemins de boot/install simples : mdraid gagne, en particulier RAID1 pour la racine.
3. Si vous exécutez des bases de données et pouvez vous permettre des miroirs : mdraid RAID10 ou mirrors ZFS. Évitez la parité RAID pour l’OLTP chaud sauf tests approfondis.
4. Si vous comptez sur les snapshots pour RPO/RTO : ZFS offre l’histoire opérationnelle la plus propre.
5. Si votre budget RAM est serré : mdraid + XFS/ext4 demande généralement moins.
6. Si votre org a des workflows conformité LUKS : mdraid s’intègre naturellement ; le chiffrement ZFS est correct mais diffère opérationnellement.

Plan de déploiement en production (étapes sûres)

1. Choisissez le niveau RAID en fonction du domaine de défaillance et de la fenêtre de rebuild, pas seulement de la capacité.
2. Standardisez les modèles de disques au sein d’un vdev/array quand possible ; évitez de mélanger SMR et CMR là où cela compte.
3. Activez le monitoring avant la mise en production : alertes mdadm, alertes SMART, état des pools ZFS, statut des scrubs, graphes de latence et de saturation I/O.
4. Définissez la politique de scrub/check :
   • ZFS : zpool scrub régulier et alertez sur les octets réparés ou erreurs checksum.
   • mdraid : checks de consistance périodiques (et comprenez ce qu’ils garantissent ou non).
5. Testez la procédure de remplacement de disque sur un nœud non-prod avec votre matériel exact.
6. Documentez l’impact de performance du rebuild/resilver et définissez quand throttler.
7. Sauvegardes : implémentez et testez la restauration, pas seulement les jobs de sauvegarde.
8. Faites un game day : simulez une panne d’un disque, puis un second disque « instable », et observez le comportement humain.

Plan d’intervention pour un array/pool dégradé

1. Geler les changements : arrêter les « optimisations », arrêter les rebalances, arrêter les redémarrages aléatoires.
2. Collecter l’état : /proc/mdstat + mdadm --detail ou zpool status.
3. Identifier le composant défaillant : SMART, logs, resets de contrôleur.
4. Décider : remplacer maintenant vs throttler le rebuild vs évacuer la charge.
5. Remplacer en utilisant la séquence d’outils correcte (mdadm fail/remove/add ou zpool replace).
6. Surveiller le rebuild/resilver et guetter les erreurs secondaires.
7. Post-récupération : lancer scrub/check, puis faire une vérification ciblée des données et valider les sauvegardes.

FAQ

Est-ce que ZFS est toujours plus sûr que mdraid ?

Plus sûr contre la corruption silencieuse et de nombreux problèmes de consistance, oui—parce qu’il fait des checksums et peut s’auto-réparer avec redondance.
Mais ZFS dépend toujours d’un matériel sain. Une mauvaise RAM ou un contrôleur malhonnête peuvent pourrir la journée de n’importe qui.

Est-ce que mdraid est « obsolète » maintenant que ZFS existe ?

Non. mdraid reste un bloc de construction solide pour les fermes Linux, en particulier pour RAID1/10 et pour des environnements qui exigent portabilité et simplicité.
Ce n’est pas tendance ; c’est serviciel. La production préfère le serviciel.

Dois-je utiliser mdraid RAID5 pour des données importantes ?

Si « important » signifie « je ne peux pas tolérer la corruption silencieuse », évitez-le. Si vous devez utiliser une parité RAID, atténuez fortement :
UPS, write-intent bitmap, monitoring robuste, sauvegardes vérifiées et procédures de récupération documentées. Ou utilisez RAIDZ ZFS à la place.

Pourquoi les rebuilds mdraid semblent-ils pires que les resilvers ZFS ?

Le rebuild mdraid touche souvent de larges portions du device (selon le niveau et l’usage du bitmap).
Le resilver ZFS copie typiquement seulement les blocs alloués, ce qui peut être bien moins de données—sauf si le pool est presque plein ou très fragmenté.

Puis-je empiler ZFS sur mdraid ?

Vous pouvez, mais vous ne devriez généralement pas. Vous dupliquez la logique RAID, compliquez les modes de défaillance et embrouillez l’endroit où l’intégrité réside.
Si vous voulez les fonctionnalités ZFS, donnez à ZFS des disques directs (HBAs, pas des contrôleurs RAID) et laissez-le faire son travail.

Quel est le meilleur niveau RAID pour les bases de données ?

Les miroirs sont la réponse par défaut : mdraid RAID10 ou mirrors ZFS. La parité RAID peut convenir pour certaines charges orientées lecture ou par lots,
mais elle est moins indulgente et souvent moins prévisible sous pression d’écriture.

Ai-je besoin de RAM ECC pour ZFS ?

C’est fortement recommandé pour les systèmes où la correction compte. ZFS détectera la corruption disque ; il ne peut pas empêcher la RAM défectueuse
de générer de mauvaises données avant checksum. L’ECC réduit substantiellement cette catégorie de risque.

La compression ZFS est-elle sûre et utile ?

Oui—lz4 est largement utilisé et typiquement bénéfique, surtout pour le texte, les logs, les images VM et beaucoup de bases de données.
Elle peut réduire l’I/O et augmenter le débit effectif. Mesurez la charge CPU, mais la plupart des CPUs modernes gèrent cela confortablement.

Quel est l’équivalent mdraid du scrub ZFS ?

mdraid peut faire des vérifications de consistance, mais il n’offre pas de checksums de bout en bout. Un contrôle de parité peut détecter une discordance parité/données,
mais il ne peut pas prouver la correction des données utilisateur comme le fait ZFS.

Comment choisir entre ZFS RAIDZ2 et mdraid RAID6 ?

Si vous voulez la parité avec de meilleures garanties de correction et des outils intégrés, RAIDZ2 est généralement un meilleur choix opérationnel.
Si vous avez besoin d’un périphérique bloc pour des stacks existants et que vous êtes confiant dans vos mitigations opérationnelles, RAID6 est viable—mais traitez les événements de perte de courant sérieusement.

Étapes pratiques suivantes

Si vous construisez un nouveau stockage pour la production et que vous n’avez pas de contrainte spéciale vous poussant ailleurs, par défaut choisissez mirrors ZFS ou RAIDZ2,
gardez le design simple et programmez des scrubs réguliers avec alerting. Associez-le à de la RAM ECC quand vous le pouvez. Faites des snapshots partie intégrante de votre stratégie de sauvegarde,
pas une réflexion après coup.

Si vous êtes déjà sur mdraid et que cela fonctionne : ne migrez pas en panique. Serrez plutôt les opérations :
vérifiez le monitoring SMART, confirmez votre stratégie de throttling de rebuild, ajoutez le write-intent bitmap quand approprié, et exercez les procédures de récupération.
Ensuite décidez si les fonctionnalités d’intégrité (et pas seulement la performance) justifient une migration vers ZFS pour des jeux de données spécifiques comme les sauvegardes et les partages de fichiers.

Le meilleur choix est celui que votre équipe peut exploiter correctement sous stress. Le deuxième meilleur choix est celui qui échoue assez bruyamment pour que vous le remarquiez.