Passage des contrôleurs RAID pour ZFS : mode IT vs HBA vs « Faux HBA »

Le principe : ZFS veut des disques, pas des opinions

ZFS est un système de fichiers et un gestionnaire de volumes. Ce n’est pas un slogan ; c’est un contrat de conception. ZFS s’attend à voir les disques réels (ou au moins quelque chose qui se comporte comme des disques) parce qu’il veut :

• contrôler la redondance (miroirs, RAIDZ) et la comprendre de bout en bout,
• suivre les checksums et réparer à l’aide des copies redondantes,
• gérer l’ordre des écritures et la sémantique des flushs,
• observer les erreurs d’E/S et agir en conséquence (marquer un périphérique défaillant, resilver, scrub),
• voir l’identité et la topologie (numéros de série, chemins) afin de survivre aux bizarreries de câbles/contrôleurs.

Les contrôleurs RAID matériels ont été conçus pour un contrat différent : abstraire les disques en « lecteurs virtuels », masquer les mauvais blocs, réessayer en interne, réordonner les écritures et, en général, fournir l’illusion que tout va bien. Le point essentiel de ZFS est que le monde n’est pas parfait, et faire semblant conduit au genre de perte de données qui ressemble à une « corruption aléatoire » jusqu’à ce que vous réalisiez que c’était déterministe depuis le départ.

L’objectif, si vous exécutez ZFS, est simple : présenter chaque disque physique à l’OS avec une traduction minimale. C’est là que le mode IT et les HBA appropriés excellent. Et c’est là que les contrôleurs RAID en « passthrough » vous mentent parfois.

Termes que les fournisseurs abusent : mode IT, HBA, JBOD, passthrough

Mode IT (Initiator-Target mode)

Dans l’écosystème LSI/Broadcom (et la plupart des cartes rebrandées : Dell PERC, IBM ServeRAID, Fujitsu, etc.), le « mode IT » est un firmware qui transforme un contrôleur RAID capable en un simple initiateur SAS. Il cesse d’exécuter la virtualisation RAID et expose chaque disque comme sa propre cible.

« Mode IT » n’est pas un terme universel chez tous les fournisseurs, mais en pratique c’est un raccourci pour « firmware HBA sur un contrôleur SAS LSI ».

HBA (Host Bus Adapter)

Un véritable HBA est un contrôleur conçu pour attacher des disques et les exposer tels quels. Pas de pile RAID, pas de couche de lecteurs virtuels, pas de cache en écriture qui fait semblant d’être votre système de fichiers. Il peut supporter des expanders SAS, le multipath et des profondeurs de file d’attente élevées. C’est l’équivalent stockage d’une bonne clé à molette : pas excitant, toujours là.

Mode JBOD

JBOD est là où les choses deviennent glissantes. Certains contrôleurs ont une option « JBOD » qui crée un « lecteur virtuel » par disque physique. Parfois c’est assez proche. Parfois c’est un wrapper RAID0 autour de chaque disque avec de l’état supplémentaire, du caching, du remappage et de la gestion d’erreurs. ZFS peut fonctionner dessus, mais vous avez inséré une couche de traduction qui peut masquer des erreurs et rompre des hypothèses.

Passthrough

« Passthrough » peut signifier :

• que l’OS obtient des périphériques SCSI/SAS directement, y compris les numéros de série et SMART,
• ou que l’OS obtient un périphérique virtuel qui relaie la plupart des commandes mais pas toutes,
• ou que l’OS obtient un « objet ressemblant à un disque » qui partage juste assez de réalité pour démarrer.

Quand quelqu’un dit « passthrough », votre prochaine question doit être : passthrough de quoi, exactement ? Les erreurs ? Les flushs ? SMART ? La profondeur de file d’attente ? TRIM ? Le comportement en cas de perte de puissance ? Parce que c’est là que les corps sont enterrés.

Mode IT : ce que c’est, ce que ça apporte, ce qui peut encore mal tourner

Le mode IT est le point idéal pour de nombreuses configurations ZFS parce qu’il est largement disponible, peu coûteux sur le marché secondaire et stable dans les pilotes d’OS mainstream (Linux mpt2sas/mpt3sas, FreeBSD mps/mpr). Vous obtenez des disques physiques qui apparaissent comme des disques physiques. ZFS peut faire son travail.

Ce que vous gagnez avec le mode IT

• Visibilité directe des disques : numéros de série, WWN et identifiants de périphérique prévisibles.
• Rapports d’erreurs honnêtes : les erreurs médias remontent à l’OS ; ZFS peut marquer les disques fautifs.
• Sémantique de flush prévisible : les flushs de cache disque ne sont pas « utilement » réinterprétés par le firmware RAID.
• Moins de bêtises sur le chemin d’écriture : pas de cache en écriture qui tente de survivre à une perte de puissance.
• Meilleure compatibilité : des outils comme smartctl et sg_ses se comportent généralement correctement.

Ce qui peut encore mal tourner

Le mode IT ne corrige pas magiquement la physique. Vos goulots deviennent simplement plus honnêtes.

• Mauvais câbles/backplanes : SAS est robuste jusqu’à ce qu’il ne le soit plus. Un simple câble mini-SAS marginal peut se transformer en réinitialisations de lien et en timeouts qui ressemblent à des « erreurs disque aléatoires ».
• Expanders sous charge : les expanders bon marché peuvent introduire du head-of-line blocking, surtout avec de nombreux HDD en scrub simultané.
• Mismatch de profondeur de file d’attente : trop peu et vous perdez du débit ; trop et vous gonflez la latence en cas de contentions.
• Incompatibilité de firmware : mélanger des générations de firmware peut fonctionner, jusqu’à ce qu’un modèle de disque tombe dans un cas limite. Le stockage est un musée de cas limites.
• Thermique : les HBA chauffent. « Ça marche en labo » devient « flapping de lien en production » quand le flux d’air du châssis n’est pas réel.

Blague n°1 : Un HBA sans flux d’air, c’est comme une base de données sans sauvegardes — techniquement fonctionnel jusqu’à ce qu’il devienne votre problème personnel.

Véritables HBA : ennuyeux, corrects, assez rapides

Si vous avez le choix, un véritable HBA est l’option la moins surprenante pour ZFS. C’est un compliment. La production aime « le moins surprenant ».

Les HBA « véritables » modernes sont généralement SAS3 (12Gbps) ou SAS4 (24Gbps), prennent correctement en charge les expanders et ont des pilotes éprouvés par une décennie d’utilisation réelle. Avec des pools HDD, vous atteindrez les limites des disques bien avant celles de l’HBA. Avec des pools SSD, le choix d’HBA compte davantage, mais la règle reste : simplifiez le chemin.

Les différences pratiques que vous remarquez avec un véritable HBA :

• L’identité des disques reste stable au reboot et aux rescans.
• SMART et les compteurs d’erreurs sont lisibles sans incantations spécifiques au contrôleur.
• La gestion des fautes par ZFS se comporte de façon prévisible quand un disque se dégrade.
• La latence est « juste les disques » plus l’overhead du bus, pas « disques plus comité firmware ».

« Faux HBA » : contrôleurs RAID déguisés en passthrough

Définissons « faux HBA » clairement : un contrôleur RAID qui prétend exposer des disques individuels mais conserve toujours une couche d’abstraction héritée de l’ère RAID devant eux. Parfois on appelle ça JBOD, parfois « mode HBA », parfois « passthrough ». Ce n’est pas toujours malveillant. C’est juste pas toujours honnête.

Pourquoi ça existe

Les fournisseurs ont construit des contrôleurs RAID pour des datacenters à l’ère Windows/VMware où le contrôleur était le cerveau du stockage. Puis ZFS (et le RAID logiciel en général) est devenu mainstream, et soudain tout le monde voulait « juste un disque ». Plutôt que de redesigner le silicium, les fournisseurs ont souvent livré une fonctionnalité firmware qui approximait l’exposition des disques.

Ce que « faux HBA » casse

• Transparence SMART : vous pouvez voir un SMART partiel, rien, ou il peut être mappé via des pages spécifiques au contrôleur.
• Sémantique des erreurs : le contrôleur peut réessayer et cacher des médias marginaux, transformant un disque en échec en pics de latence longs au lieu d’erreurs propres.
• Barrières d’écriture/flush : le contrôleur peut acquitter les flushs tôt à cause de sa politique de cache.
• Identité du périphérique : les disques apparaissent comme « Virtual Disk 0 » plutôt que des serials/WWN stables.
• Comportement de récupération : lors de réinitialisations ou d’événements d’alimentation, le contrôleur peut réordonner ce que l’OS voit et quand.

Quand c’est « suffisamment bon »

Parfois vous héritez d’un matériel et vous ne pouvez pas le changer ce trimestre. Si le contrôleur fournit un vrai JBOD qui expose chaque disque avec des identifiants stables et le SMART complet, et si vous pouvez désactiver proprement le caching et le read-ahead, vous pouvez le faire fonctionner. La question est : pouvez-vous vérifier tout cela, de façon répétée, et détecter quand une mise à jour du firmware change le comportement ?

Quand c’est un non catégorique

Si vous ne pouvez pas obtenir un SMART fiable, si les identifiants de disque sont instables, si ZFS voit des timeouts étranges pendant les scrubs, ou si le contrôleur requiert des wrappers de lecteur virtuel par disque, arrêtez de négocier. Remplacez-le par un HBA. L’argent que vous « économisez » sera dépensé en réponse aux incidents. Et vous le paierez en week-ends.

Blague n°2 : Un contrôleur RAID en « mode passthrough » est comme une réunion qui « aurait pu être un e‑mail » — prend quand même deux heures et casse votre après-midi.

Faits et contexte historique intéressants (court et utile)

1. ZFS est né dans une ère de disques menteurs. Les premiers disques SATA et contrôleurs commodity réordonnaient agressivement les écritures ; l’accent de ZFS sur les checksums de bout en bout était en partie une réponse.
2. Le « mode IT » vient du monde SAS, pas du monde ZFS. Le firmware Initiator-Target était destiné aux hôtes qui voulaient juste parler SAS sans logique RAID au milieu.
3. Beaucoup de cartes « contrôleur RAID » célèbres sont juste des rebrands de silicium LSI. Les gammes Dell PERC et IBM ServeRAID mappent souvent aux mêmes familles de puces, avec des contraintes firmware différentes.
4. Le cache en écriture était historiquement un pansement pour disques lents. Il améliorait énormément les benchmarks, mais il faisait aussi de la correction en cas de perte de puissance le problème de quelqu’un d’autre — souvent le vôtre.
5. Le cache sur batterie a évolué vers le cache sur flash. Les batteries vieillissent et gonflent ; les modules flash avec supercap deviennent courants pour préserver le contenu du cache sans babysitter une batterie.
6. SMART n’a pas été conçu pour les contrôleurs RAID. Les contrôleurs qui se situent entre l’OS et le disque ont souvent besoin de mécanismes de passthrough spécifiques au fournisseur ; pas tous les implémentent complètement.
7. Les expanders SAS sont essentiellement des commutateurs Ethernet pour disques. Ils multiplexent les lignes ; les bons se comportent, les mauvais introduisent des motifs de congestion subtils pendant les scrubs/resilvers.
8. La profondeur de file d’attente est devenue le bouton de performance discret. Avec la montée des SSD, la capacité à soutenir de nombreuses commandes en attente a compté plus que la vitesse brute du lien.
9. Certains contrôleurs présentent un RAID0 par disque comme « JBOD ». Ça ressemble à un disque, ça sent comme un disque, et ça contient quand même des métadonnées et un état politique qui peuvent vous mordre plus tard.

Que acheter et quoi éviter (point de vue)

Acheter ceci

• Un véritable HBA (SAS3/SAS4) bien supporté par votre OS, surtout si vous utilisez des SSD ou un grand nombre de disques.
• Un contrôleur LSI/Broadcom flashé en mode IT si vous êtes à l’aise pour valider le firmware et garder des pièces de rechange.
• De bons câbles et un backplane sensé. La plupart des « problèmes de contrôleur » sont des problèmes de cuivre qui portent un autre chapeau.

Éviter ceci

• Le RAID matériel pour ZFS (vraies grilles). ZFS au‑dessus d’un disque virtuel RAID5/6, c’est exactement ce qui génère des erreurs de checksum que vous ne pouvez pas réparer.
• Le « JBOD » qui est en réalité des wrappers RAID0 par disque, surtout si vous ne pouvez pas lire SMART proprement.
• Les contrôleurs qui ne peuvent pas transmettre les serials/WWN des disques. Si vous ne pouvez pas identifier de manière fiable un disque défaillant, vous finirez par retirer le mauvais disque.
• Toute configuration où vous ne pouvez pas désactiver le cache en écriture ou au moins vérifier le comportement des flushs. ZFS a besoin de barrières vraies, pas d’impressions.

La citation

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

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

Ce ne sont pas des commandes « jouet ». Ce sont celles que vous lancez quand vous décidez si vous avez un vrai HBA, si le passthrough ment, et où votre performance est partie. Les exemples supposent Linux, mais la logique s’applique ailleurs.

Task 1: Identify the controller and its driver

cr0x@server:~$ lspci -nn | egrep -i 'sas|scsi|raid'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)
04:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [1000:005d] (rev 02)

Ce que ça signifie : La première ligne est un contrôleur Fusion-MPT SAS (souvent utilisé comme HBA/device mode IT). La seconde est MegaRAID (personnalité RAID).

Décision : Préférez le périphérique Fusion-MPT pour ZFS. Si vous devez utiliser le MegaRAID, planifiez une validation agressive du comportement « JBOD » ou remplacez‑le.

Task 2: Confirm which kernel modules are in use

cr0x@server:~$ lsmod | egrep 'mpt3sas|megaraid|aacraid|hpsa'
mpt3sas               307200  2
megaraid_sas          180224  0

Ce que ça signifie : mpt3sas est typique pour les HBA/IT mode LSI SAS3 ; megaraid_sas indique une pile RAID.

Décision : Si vos disques sont derrière megaraid_sas, supposez que vous avez peut‑être un « faux HBA » jusqu’à preuve du contraire.

Task 3: Map disks to controller paths and check if they look “virtual”

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,HCTL,TYPE,SIZE
NAME   MODEL              SERIAL          HCTL       TYPE  SIZE
sda    ST12000NM0008      ZHZ123AB        3:0:0:0    disk  10.9T
sdb    ST12000NM0008      ZHZ124CD        3:0:1:0    disk  10.9T
sdc    MR9361-8i          00c0ffee        4:2:0:0    disk  7.3T

Ce que ça signifie : sda/sdb montrent le modèle/serial réels. sdc montre le modèle du contrôleur comme « disk model » — présentation classique de disque virtuel.

Décision : Ne construisez pas un pool ZFS sur sdc à moins de comprendre exactement ce qui est virtualisé et pourquoi.

Task 4: Verify ZFS sees stable identifiers (WWN) and not just /dev/sdX

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'wwn|scsi'
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d4 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d5 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:11 scsi-35000c500a1b2c3d4 -> ../../sda

Ce que ça signifie : Des identifiants basés WWN existent et sont stables au reboot (tant que le contrôleur ne réécrit pas l’identité).

Décision : Utilisez les chemins /dev/disk/by-id/wwn-* lors de la création des pools. Si vous n’avez pas de WWN, considérez cela comme un signal d’alarme.

Task 5: Check if SMART works directly (best sign of real passthrough)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep 'Model Family|Device Model|Serial Number|SMART overall-health'
Model Family:     Seagate IronWolf Pro
Device Model:     ST12000NM0008
Serial Number:    ZHZ123AB
SMART overall-health self-assessment test result: PASSED

Ce que ça signifie : L’accès direct à SMART sur /dev/sda fonctionne normalement.

Décision : Ce chemin disque est « suffisamment réel » pour ZFS. Répétez pour tous les disques ; une baie/backplane défaillante peut être l’exception.

Task 6: SMART behind MegaRAID (if you must), and what failure looks like

cr0x@server:~$ sudo smartctl -a /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
Smartctl open device: /dev/sdc failed: DELL or MegaRaid controller, please try adding '-d megaraid,N'

Ce que ça signifie : L’OS voit un disque virtuel. SMART n’est pas directement visible.

Décision : Si vous continuez, vous dépendez désormais d’outils spécifiques au contrôleur (-d megaraid,N) et de leur exactitude. Pour ZFS, c’est un pas en arrière.

Task 7: Confirm physical drive visibility behind MegaRAID (controller-specific)

cr0x@server:~$ sudo smartctl -a -d megaraid,0 /dev/sdc | egrep 'Device Model|Serial Number|SMART overall-health'
Device Model:     ST12000NM0008
Serial Number:    ZHZ999XY
SMART overall-health self-assessment test result: PASSED

Ce que ça signifie : Vous pouvez accéder au SMART du disque physique via un index de couche RAID.

Décision : C’est mieux que rien, mais vous devez assurer que ZFS reçoit des erreurs d’E/S honnêtes et un comportement de flush correct. L’accès SMART seul ne certifie pas la qualité du passthrough.

Task 8: Check ZFS pool topology and confirm it uses by-id paths

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

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0

Ce que ça signifie : ZFS est ancré sur des identifiants de périphérique stables, pas sur /dev/sdX.

Décision : Si vous voyez /dev/sdX en production, planifiez une fenêtre de maintenance pour corriger cela. C’est une panne différée.

Task 9: Spot controller-induced latency spikes during scrub

cr0x@server:~$ sudo zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  21.4T    220     15   420M  2.1M
  raidz2    12.3T  21.4T    220     15   420M  2.1M
    wwn-...      -      -     55      4   105M  0.6M
    wwn-...      -      -     54      4   104M  0.5M
    wwn-...      -      -     56      3   107M  0.6M
    wwn-...      -      -     55      4   104M  0.4M

Ce que ça signifie : Les lectures sont équilibrées. Aucun disque évident en anomalie.

Décision : Si un disque montre une bande passante drastiquement inférieure ou des ops proches de zéro pendant un scrub, suspectez un disque défaillant, une voie défaillante, un problème d’expander ou une tempête de réessais du contrôleur qui masque des erreurs.

Task 10: Check for link resets and command timeouts (classic “it’s the cable” proof)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt3sas|sas|reset|timeout|link'
[Thu Dec 26 09:22:11 2025] mpt3sas_cm0: SAS host is non-operational !!!!
[Thu Dec 26 09:22:12 2025] mpt3sas_cm0: sending diag reset !!
[Thu Dec 26 09:22:20 2025] sd 3:0:1:0: [sdb] tag#129 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK

Ce que ça signifie : L’HBA a réinitialisé ou le lien a merdé. Les disques commencent à timeout.

Décision : Avant d’accuser ZFS, remplacez/remettez les câbles et vérifiez l’alimentation/le flux d’air du backplane. Si cela se répète sous charge, vous flirtiez avec l’instabilité du pool.

Task 11: Validate write cache policy at the drive level

cr0x@server:~$ sudo hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)

Ce que ça signifie : Le cache d’écriture du disque est activé. Ça peut aller si les flushs sont respectés et que l’alimentation est stable ; sinon c’est épicé.

Décision : Si vous ne pouvez pas garantir la protection contre la perte de puissance (UPS, arrêt propre, ou SSD PLP), pensez à désactiver le cache d’écriture sur les HDD pour des sémantiques plus sûres — en acceptant une baisse de performance.

Task 12: Check whether barriers/flush are being issued (symptom-driven)

cr0x@server:~$ sudo cat /sys/block/sda/queue/write_cache
write back

Ce que ça signifie : Le noyau croit que le périphérique utilise du write-back caching. Cela augmente l’importance d’un comportement de flush correct.

Décision : Sur les contrôleurs « faux HBA », c’est le moment où vous devenez nerveux : est‑ce que le contrôleur flush réellement le disque, ou juste son propre cache ?

Task 13: Confirm TRIM/discard support for SSD pools (and detect virtualization)

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME  DISC-GRAN DISC-MAX DISC-ZERO
sda         4K       2G         0
sdb         4K       2G         0
sdc         0B       0B         0

Ce que ça signifie : sda/sdb supportent discard. sdc ne le supporte pas, ce qui est courant pour des disques virtuels derrière un contrôleur RAID.

Décision : Pour des pools SSD lourds, l’absence de discard est un problème de performance et d’endurance. Préférez les HBA véritables ou des contrôleurs avec passthrough vérifié.

Task 14: Measure queue depth and sanity-check saturation

cr0x@server:~$ cat /sys/block/sda/device/queue_depth
32

Ce que ça signifie : La profondeur de file d’attente du périphérique est 32. Ça peut convenir pour des HDD ; les SSD et les charges concurrentes lourdes peuvent en vouloir plus, mais ça dépend du contrôleur et de la charge.

Décision : Si la latence pique sous charge parallèle, ne montez pas la profondeur de file d’attente sans réflexion. Confirmez d’abord que vous ne cachez pas des erreurs ou que vous ne frappez pas des goulots d’expander.

Task 15: Check controller firmware/BIOS version (change control fuel)

cr0x@server:~$ sudo lshw -class storage -short
H/W path   Device  Class          Description
/0/100/3           storage        Serial Attached SCSI controller
/0/100/4           storage        RAID bus controller

Ce que ça signifie : Vous avez identifié les périphériques de stockage, mais pas le firmware. L’étape suivante est l’outillage du fournisseur ou storcli/sas3flash selon la famille de contrôleur.

Décision : Suivez les versions de firmware dans votre CMDB ou au moins vos notes de build. « Ça a changé » est la moitié de chaque postmortem.

Méthode de diagnostic rapide (trouver le goulot vite)

Quand les performances ZFS s’effondrent ou qu’un pool commence à émettre des erreurs, vous n’avez pas le temps pour la philosophie. Vous avez besoin d’une boucle serrée qui vous dit : est‑ce le disque, le contrôleur, le chemin ou ZFS lui‑même ?

Première étape : ZFS est‑il mécontent, ou le matériel ment‑il ?

• Lancez zpool status -P. Cherchez des incréments READ/WRITE/CKSUM et des périphériques degradés/faulted.
• Vérifiez si les chemins des périphériques sont stables (/dev/disk/by-id/wwn-*).
• Si des erreurs apparaissent seulement comme des timeouts/réinitialisations dans dmesg sans marquage clair de disque, suspectez le câblage/HBA/expander.

Deuxième étape : trouvez le composant lent sous charge

• Exécutez zpool iostat -v pool 5 durant le problème. Identifiez les disques outliers avec faible bande passante ou ops arrêtées.
• Corrélez avec iostat -x 5 pour voir l’utilisation des périphériques et les temps d’attente.
• Si un disque montre un await énorme et un faible throughput, il est probablement en train de tomber en panne ou de réessayer. Si tous les disques montrent un await élevé simultanément, suspectez un goulot contrôleur/expander ou une tempête de sync induite par la charge.

Troisième étape : vérifiez le mode du contrôleur et la transparence

• Vérifiez lspci + lsmod pour confirmer la pile de pilotes (mpt3sas bon, megaraid_sas nécessite examen).
• Confirmez le passthrough SMART. Si vous avez besoin d’indexes du contrôleur pour lire SMART, vous avez peut‑être un « faux HBA ».
• Vérifiez le support discard pour les SSD (lsblk -D).

Quatrième étape : décidez si c’est « remplacer le disque » ou « remplacer contrôleur/câble »

• Remplacer le disque si SMART montre des secteurs réalloués/pending, des erreurs médias, ou si ZFS marque systématiquement ce disque.
• Remplacer/remettre le câble/backplane si les erreurs suivent le déplacement du disque, ou si les logs montrent des réinitialisations de lien affectant plusieurs disques.
• Remplacer le contrôleur si vous voyez des réinitialisations HBA récurrentes, des timeouts de commande sur de nombreux disques, ou une virtualisation qui bloque une surveillance fiable.

Erreurs courantes : symptôme → cause racine → correction

1) Les scrubs sont terriblement lents et « se bloquent » aléatoirement

Symptôme : Le scrub commence vite, puis le débit s’effondre ; parfois un seul disque affiche 0 ops pendant de longues périodes.

Cause racine : Tempêtes de réessais du contrôleur masquant un média marginal, ou problème de lien SAS causant des réinitialisations ; les expanders amplifient le phénomène.

Correction : Vérifiez dmesg pour des resets/timeouts, swappez les câbles, déplacez le disque suspect vers une autre baie et lancez des tests SMART longs. Si derrière une couche RAID passthrough, envisagez fortement de migrer vers le mode IT/un vrai HBA.

2) Erreurs de checksum ZFS que vous ne pouvez pas réparer

Symptôme : CKSUM augmente ; les scrubs trouvent des erreurs ; les réparations ne tiennent pas ou les erreurs réapparaissent.

Cause racine : ZFS au‑dessus d’un disque virtuel RAID, ou un contrôleur qui effectue du remappage silencieux/caching qui brise les hypothèses end‑to‑end.

Correction : Arrêtez d’utiliser des arrays RAID matériels sous ZFS. Reconstruisez avec des disques directs (HBA/mode IT). Si vous ne pouvez pas, assurez‑vous au moins qu’un disque corresponde à un périphérique avec un reporting d’erreur complet — mais considérez cela temporaire.

3) Après un reboot, les disques « ont changé de nom » et le pool n’importe pas proprement

Symptôme : L’import du pool se plaint de périphériques manquants ; l’ordre de /dev/sdX a changé.

Cause racine : Pool créé en utilisant /dev/sdX ; énumération instable ; la virtualisation du contrôleur peut aggraver cela.

Correction : Utilisez les chemins by-id et exportez/importez soigneusement. Remplacez le mode du contrôleur s’il réécrit l’identité.

4) Les données SMART semblent vides ou génériques (« Modèle inconnu »)

Symptôme : Les requêtes SMART échouent sauf avec des flags spéciaux ; le modèle s’affiche comme le contrôleur.

Cause racine : Disques virtuels présentés par le firmware RAID, pas les disques physiques.

Correction : Utilisez un HBA/mode IT si possible. Si vous êtes coincé, configurez la supervision via des méthodes spécifiques au contrôleur et vérifiez qu’elles couvrent tous les disques et attributs qui vous importent.

5) La performance semble excellente jusqu’à un événement de coupure, puis le pool fait des drames

Symptôme : Après une perte totale de puissance, le pool s’importe mais a des erreurs, ou vous voyez des données récemment écrites manquantes suspectes.

Cause racine : Cache en écriture au niveau du contrôleur acquittant les écritures tôt ; les flushs ne sont pas honorés end‑to‑end.

Correction : Désactivez le cache en écriture (contrôleur et disques) à moins d’avoir une protection contre la perte de puissance vérifiée et un comportement de flush correct. Préférez des HBA plus simples pour ZFS.

6) Événements aléatoires de « défaillance » multi‑disques pendant I/O intense

Symptôme : Plusieurs disques journalisent des erreurs en même temps ; ZFS rapporte des timeouts ; puis tout « se rétablit ».

Cause racine : Surchauffe de l’HBA, saturation d’expander ou instabilité PSU/backplane provoquant des chutes de lien momentanées.

Correction : Améliorez le flux d’air sur le radiateur de l’HBA, validez l’alimentation et les connecteurs du backplane, et évitez les expanders bon marché pour des boîtiers à grand nombre de disques.

Trois mini-histoires d’entreprise issues des tranchées du stockage

Incident causé par une mauvaise hypothèse : « Passthrough signifie passthrough »

Une entreprise SaaS de taille moyenne a hérité d’une paire de serveurs de stockage lors d’un remaniement rapide d’équipe. Le précédent propriétaire avait laissé une note : « Contrôleur en passthrough, ZFS gère la redondance. » Tout le monde hocha la tête. Ça démarra, le pool s’importa, les tableaux de bord étaient verts. L’équipe avait des incendies plus gros.

Des mois plus tard, ils observèrent un motif : des pics de latence périodiques sur la réplique primaire de la base, toujours pendant les fenêtres de scrub. Aucun disque évident ne montrait de défaillance. ZFS ne marquait rien, mais la latence applicative passait de « correcte » à « clients mécontents » en quelques minutes. L’astreinte a fini par couper les alertes, désactiver les scrubs et promettre de revenir dessus.

La révision eut lieu après un arrêt non propre pendant des travaux de maintenance du bâtiment. Le pool revint, mais ZFS signala des erreurs de checksum ne corrélant avec aucun disque unique. Pire, le motif d’erreurs se déplaçait entre les scrubs. L’équipe soupçonna la RAM, puis des bugs du noyau, puis des rayons cosmiques. Le brouillon du postmortem blâmait déjà la « complexité ZFS ».

Le vrai problème : le « passthrough » du contrôleur RAID était un wrapper de disque virtuel avec le write‑back cache encore activé au niveau du contrôleur. Les flushs n’étaient pas honorés comme ZFS l’attendait. En fonctionnement normal c’était « ok » ; en scrub + charge, cela produisait des pics de latence dus aux réessais internes et au comportement du cache ; en perte de puissance c’était roulette sur la cohérence.

La correction fut brutale : remplacer le contrôleur par un HBA approprié et reconstruire le pool depuis les sauvegardes. Ils écrivirent aussi une règle de runbook : « Passthrough n’est pas une fonctionnalité ; c’est une affirmation. Vérifiez avec SMART, l’identité des disques et la politique de cache. »

Optimisation qui a mal tourné : « Activons le write‑back cache pour plus d’IOPS »

Une autre organisation utilisait ZFS pour un magasin de VM. Quelqu’un remarqua que l’activation du write‑back cache sur le contrôleur rendait les benchmarks héroïques. La demande de changement disait bien : « Améliore latence et débit ; risque atténué par UPS. » Elle fut approuvée parce que les graphiques étaient jolis et que personne ne voulait être la personne qui bloque la performance.

Pendant un moment ça marcha. La latence baissa. L’équipe célébra en augmentant les ratios de consolidation. C’est ainsi qu’on sait qu’une optimisation est culturellement adoptée : les gens commencent à en dépendre.

Puis une mise à jour firmware modifia légèrement le comportement du contrôleur autour des flushs du cache. Pas de manière dramatique. Juste assez. Sous une charge d’écritures sync intensive (les VMs adorent le sync quand on s’y attend le moins), le contrôleur acquittait parfois les écritures tôt et réordonnait certaines opérations comme ZFS ne l’anticipait pas. ZFS n’a pas tout de suite hurlé. Il fit ce qu’il put avec l’information fournie.

Des semaines plus tard, un nœud de stockage planta et s’importa avec quelques disques VM corrompus. Pas tout le pool, pas une défaillance propre — juste le genre qui ruine votre journée et votre crédibilité. L’UPS n’aida pas parce que ce n’était jamais uniquement la « perte de puissance » ; c’était une question de garanties de correction à la frontière.

Ils annulèrent le caching et acceptèrent la perte de performance. La leçon n’était pas « ne jamais optimiser ». C’était « ne jamais optimiser en violant le contrat du système de fichiers ». ZFS a déjà un cache (ARC) et sait déjà comment ordonner les écritures. Votre contrôleur ne comprend pas votre intention, seulement vos paquets.

Pratique ennuyeuse mais correcte qui a sauvé la mise : IDs stables, pièces de rechange testées et transparence du contrôleur

Une société de services financiers (le genre qui préfère les fenêtres de changement plus que les humains) standardisa sur une courte liste d’HBA. Chaque build de serveur utilisait des chemins by-id, et chaque disque était étiqueté physiquement avec le suffixe WWN. La politique paraissait pédante jusqu’à ce que vous la voyiez en action.

Un après‑midi, un pool passa en DEGRADED. ZFS marqua un disque proprement. Il n’y eut aucune ambiguïté : le chemin de zpool status -P correspondait à un WWN, et l’étiquette du châssis correspondait à la baie. Le technicien retira le bon disque du premier coup. C’est déjà plus rare que ça devrait l’être.

Voici ce qui les sauva : ils validèrent aussi le passthrough SMART et le reporting d’erreurs pendant la mise en service. Quand le disque commença à renvoyer des erreurs de lecture, ces erreurs remontèrent rapidement et de façon cohérente. ZFS n’eut pas à deviner. Il fit son boulot : réparer depuis la redondance, marquer le disque comme mauvais et continuer à servir.

Le remplacement resilvera sans drame parce que l’HBA n’injectait pas ses propres politiques de récupération. Pas de réessais cachés, pas de « disque virtuel dégradé opaque », pas d’alarmes contrôleur que seule une personne savait interpréter. Le ticket d’incident se ferma avec le commentaire le plus sec du monde : « Disque défaillant remplacé ; resilver terminé. »

Voilà le rêve : une défaillance qui se comporte comme dans la doc de conception. Le truc, c’est que ça n’arrive que si vous le construisez pour.

Listes de contrôle / plan pas à pas

Pas à pas : valider un contrôleur pour ZFS (nouvelle construction ou héritage)

1. Identifier le type de contrôleur et le pilote.
   • Exécutez lspci -nn et lsmod.
   • Objectif : pile driver HBA/mode IT (par ex. mpt3sas), pas une pile de virtualisation RAID sauf si vous avez vérifié la transparence.
2. Confirmer que l’identité des disques est réelle.
   • Exécutez lsblk -o NAME,MODEL,SERIAL.
   • Objectif : le modèle/serial du disque correspond à l’étiquette du disque, pas au modèle du contrôleur.
3. Confirmer que des chemins by-id stables existent.
   • Vérifiez /dev/disk/by-id/ pour des WWN.
   • Objectif : créer des pools en utilisant des chemins basés WWN, jamais /dev/sdX.
4. Valider que SMART fonctionne normalement pour chaque disque.
   • smartctl -a /dev/sdX devrait réussir.
   • Si cela requiert -d megaraid,N, écrivez une supervision qui le couvre et traitez le contrôleur comme un risque.
5. Valider le comportement d’erreur sous charge.
   • Lancez un scrub et surveillez zpool iostat -v.
   • Vérifiez dmesg pour des resets/timeouts.
   • Objectif : pas de flaps de lien ; tout mauvais disque doit apparaître clairement comme une erreur de disque, pas comme un chaos côté contrôleur.
6. Décider de la politique de cache délibérément.
   • Si votre contrôleur a un cache en écriture, comprenez et documentez quand il est activé et pourquoi.
   • Privilégiez la correction plutôt que les benchmarks sauf si vous avez vérifié la protection contre la perte de puissance et la sémantique des flushs end‑to‑end.

Checklist opérationnelle : chaque trimestre (oui, vraiment)

• Exécuter un scrub et confirmer qu’il se termine dans une fenêtre de temps prévisible.
• Revoir les stats SMART pour les défaillances lentes (secteurs pending, erreurs CRC).
• Vérifier ponctuellement que les IDs disque dans ZFS correspondent toujours au marquage physique.
• Vérifier que les versions de firmware n’ont pas dérivé de façon imprévisible dans la flotte.
• Tester une procédure de remplacement de disque sur un nœud non critique (la mémoire musclée compte).

Checklist de migration : passage de « faux HBA » à vrai HBA/mode IT

• Supposez que vous aurez besoin d’une fenêtre de maintenance et de sauvegardes en lesquelles vous avez confiance.
• Inventoriez la configuration actuelle du pool avec zpool status -P et sauvegardez‑la.
• Enregistrez les WWN des disques et le mapping des baies.
• Planifiez le remplacement du contrôleur et vérifiez la stratégie de disque de boot/root (ne perdez pas l’OS).
• Après le remplacement : validez SMART, discard (pour SSD) et chemins by-id stables avant d’importer/créer des pools.
• Effectuez un scrub après la première semaine de charge lourde pour détecter tôt les problèmes de chemin.

FAQ

1) Dois‑je utiliser le mode IT pour ZFS ?

Non. Vous devez fournir à ZFS des disques directs et véridiques. Le mode IT est une manière courante d’y parvenir sur des cartes basées LSI. Les véritables HBA fonctionnent aussi. Évitez les arrays RAID sous ZFS.

2) Quel est le signe le plus simple que je suis face à un « faux HBA » ?

Si lsblk affiche le modèle du contrôleur comme modèle de disque, ou si smartctl -a /dev/sdX échoue sans flags spécifiques au contrôleur, vous ne voyez probablement pas des disques bruts.

3) Est‑ce qu’un « RAID0 par disque » est acceptable pour ZFS ?

Ça peut fonctionner, mais ce n’est pas équivalent à un vrai HBA. Vous héritez de métadonnées/état par disque, de la gestion d’erreurs du contrôleur et parfois de bizarreries de caching/flush. Si c’est la production et que vous avez le choix, évitez.

4) Puis‑je exécuter ZFS au‑dessus d’un disque virtuel RAID5/6 ?

Vous pouvez, et des gens le font, et certains survivent. Mais quand vous avez de la corruption ou des cas limites de rebuild, ZFS ne peut pas guérir correctement parce qu’il ne voit pas quel périphérique physique a menti. Pour les systèmes importants, n’empilez pas des couches de redondance qui cachent les détails de défaillance.

5) Un cache sur batterie/flash rend‑il les contrôleurs RAID sûrs pour ZFS ?

Il réduit un risque (perte de puissance pendant le write‑back). Il ne résout pas le problème majeur : le contrôleur peut toujours masquer des erreurs, réécrire l’identité ou modifier la sémantique des commandes. ZFS veut de la visibilité, pas seulement « durabilité la plupart du temps ».

6) Comment savoir si les flush/barrières sont honorés ?

C’est difficile à prouver parfaitement sans tests ciblés et détails fournisseur. Pratiquement : évitez les couches qui pourraient réinterpréter les flushs, désactivez le cache en écriture du contrôleur quand possible, et préférez le mode IT/les véritables HBA où la sémantique du disque est simple.

7) Les expanders SAS fonctionnent‑ils avec ZFS ?

Oui, couramment. Le risque est la qualité et la sursouscription : lors de scrubs/resilvers avec de nombreux HDD, les expanders peuvent devenir des points de contention. Si vous voyez des resets de contrôleur ou des ralentissements constants, testez avec une configuration d’attache directe.

8) Mon pool est lent. Est‑ce l’HBA ?

Parfois, mais généralement ce sont les disques, le câblage ou des modèles de workload sync. Utilisez zpool iostat -v pour trouver les disques outliers, et dmesg pour attraper des resets de lien. Les HBA sont souvent innocents jusqu’à preuve du contraire.

9) Qu’en est‑il de la virtualisation : puis‑je passer un HBA à une VM et exécuter ZFS dedans ?

Oui, avec IOMMU/PCI passthrough, et ça peut être solide. L’essentiel est que l’invité voie de vrais disques, pas des disques virtuels fournis par l’hyperviseur ou la couche RAID. Si vous ne pouvez pas faire un passthrough complet, vous retombez dans le territoire « quelqu’un ment ».

10) Les disques SATA derrière des HBAs SAS sont‑ils acceptables ?

Oui. Les HBA SAS attachent couramment des SATA via le tunneling SATA. Soyez juste attentif aux bizarreries de gestion d’alimentation et au fait que la gestion d’erreurs SATA a historiquement été moins déterministe que SAS sous conditions de faute lourde.

Conclusion : prochaines étapes pratiques

Si vous retenez une chose : ZFS ne veut pas d’un gestionnaire de stockage intermédiaire. Il veut des disques directs, des erreurs honnêtes et une identité stable. Le mode IT et les véritables HBA fournissent cela. Les contrôleurs RAID portant un badge « passthrough » peuvent le faire, mais vous devez le vérifier — et la vérification est un travail que vous répéterez toujours.

Prochaines étapes à réaliser cette semaine :

• Inventoriez vos contrôleurs (lspci) et pilotes (lsmod) sur la flotte.
• Choisissez un hôte ZFS et validez SMART, discard (si SSD) et la stabilité by-id de bout en bout.
• Pendant votre prochain scrub, surveillez le comportement par disque avec zpool iostat -v et vérifiez les logs pour des resets/timeouts.
• Si vous trouvez un « faux HBA », décidez si vous pouvez assumer sa supervision et sa sémantique — ou planifiez le remplacement du contrôleur et terminez‑en.

La fiabilité du stockage consiste surtout à supprimer les surprises. Le chemin le plus rapide pour réduire les surprises est un HBA simple, de bons câbles et ZFS voyant ce qu’il attend : de vrais disques faisant de vraies opérations disque.