Réinitialisations de lien SATA sous ZFS : motif de défaillance contrôleur/câble

À quoi ressemble le motif « contrôleur/câble »

ZFS est terriblement honnête à propos des I/O. Il vérifie tout par checksum, il réessaie quand il le peut, et il marquera un périphérique
comme dégradé ou défaillant quand la couche sous-jacente ne peut pas livrer les blocs de façon fiable. Les réinitialisations de lien SATA vivent sous ZFS :
le noyau dit « le lien a disparu », puis « je l’ai réinitialisé », puis « il est revenu », parfois en boucle jusqu’à ce que ZFS abandonne.

Le motif « contrôleur/câble » correspond spécifiquement à lorsque le disque n’est pas la défaillance principale.
Le disque est un spectateur injustement accusé parce qu’il est le point final du transport instable.
La signature est une instabilité répétée qui se corrèle avec un chemin (port, câble, piste de backplane, expander),
et non avec le mécanisme d’un disque particulier.

Checklist terrain : signes que ce n’est pas le disque

• Plusieurs disques montrent des réinitialisations de lien, mais ils partagent le même contrôleur/backplane/rail d’alimentation.
• SMART paraît propre (pas de secteurs réalloués, pas de secteurs en attente) mais vous voyez les erreurs UDMA CRC augmenter.
• Les erreurs se regroupent autour d’un I/O élevé, de vibrations, de variations de température, ou d’une porte de châssis claquée comme si elle devait de l’argent.
• Remplacer le disque n’aide pas. Le « nouveau » disque tombe de la même façon sur le même port.
• Déplacer le même disque vers un autre port le corrige. Ce n’est pas de la magie ; c’est de l’isolation de chemin.

Voici la différence opérationnelle : un disque en fin de vie s’aggrave de façon spécifique au disque (erreurs média, lectures lentes, réallocations qui augmentent).
Un lien défaillant est plutôt chaotique (réinitialisations, timeouts, erreurs CRC, déconnexions aléatoires), affectant souvent tout ce qui est attaché à ce chemin.

Blague n°1 : SATA est le seul « bus série haute vitesse » qui peut être vaincu par un câble qui a l’air parfaitement correct. C’est essentiellement du réseau avec des vis.

Pourquoi ZFS rend ça plus visible

ZFS vérifie les lectures avec des checksums, donc une corruption transitoire sur le câble ne devient pas silencieusement des données corrompues.
À la place, ZFS journalise les erreurs de checksum, réessaie les lectures, et si la redondance existe, répare depuis une copie saine.
C’est excellent pour l’intégrité des données—et brutal pour votre astreinte quand un lien instable transforme chaque scrub en épreuve d’endurance.

Faits intéressants et contexte historique (ce qui explique la douleur d’aujourd’hui)

1. Les erreurs UDMA CRC ont été conçues comme un système d’alerte précoce. Elles indiquent souvent des problèmes de câblage/intégrité du signal plutôt que des défauts du média.
2. SATA a hérité d’une culture « ça doit aller » venant des PC de bureau. Les racks d’entreprise exigent des tolérances plus strictes que les boîtiers grand public.
3. NCQ (Native Command Queuing) a amélioré le débit mais élargi le rayon d’impact des glitchs de lien. Plus de commandes en attente signifie plus de possibilités de timeout quand le bus bloque.
4. Les backplanes ne sont pas de la magie passive. Même « juste une carte » peut avoir des pistes marginales, des connecteurs usés, ou une mise à la terre médiocre qui se manifeste par des CRC/retries.
5. AHCI a été conçu pour la généralité, pas pour l’héroïsme. Beaucoup de contrôleurs SATA intégrés se comportent mal sous tempêtes d’erreurs comparés à de vrais HBA.
6. La sémantique du hot-swap est délicate sur SATA. SAS a été conçu pour le hot-plug ; SATA le permet, mais les implémentations varient beaucoup.
7. Les fonctionnalités de gestion d’alimentation (HIPM/DIPM, ALPM) ont causé des instabilités réelles. Des changements agressifs d’état du lien peuvent déclencher des réinitialisations sur des configurations marginales.
8. Les habitudes de câblage pour le SATA 3Gb/s n’ont pas toujours survécu au 6Gb/s. « Ça marchait pendant des années » peut être un artefact d’un taux de signalisation plus bas.
9. ZFS a rendu les erreurs de checksum visibles dans les opérations. Les piles traditionnelles masquaient souvent la corruption transitoire par « réessayer jusqu’à ce que ça marche » ; ZFS vous dit la vérité.

Plan de diagnostic rapide

C’est le plan « j’ai besoin d’une direction en 10 minutes ». Ne noyez pas le poisson. Établissez si vous avez :
(a) un seul disque défaillant, (b) un lien/chemin instable, ou (c) un problème contrôleur/backplane/alimentation qui peut dégrader le pool.

Première étape : confirmez ce que ZFS pense qu’il se passe

• Vérifiez zpool status -v et notez quels vdev(s) et quels périphériques montrent des erreurs.
• Recherchez des motifs : même famille de port HBA, même boîtier, même backplane, même alimentation.

Deuxième étape : lisez l’histoire du noyau, pas seulement le résumé de ZFS

• Sortez dmesg -T et/ou journalctl -k autour du moment de l’incident.
• Recherchez : link is slow to respond, hard resetting link, COMRESET failed, SError, failed command: READ FPDMA QUEUED.

Troisième étape : décidez « disque vs chemin » avec SMART et les compteurs

• smartctl -a pour Reallocated/Pending/Offline_Uncorrectable (santé média) et UDMA CRC errors (santé du lien).
• Si les erreurs CRC augmentent tandis que les compteurs média restent stables, traitez le cas comme câble/backplane/contrôleur jusqu’à preuve du contraire.

Quatrième étape : isolez en ne changeant qu’une variable

• Déplacez le disque vers un autre port/câble/emplacement de backplane (un changement à la fois).
• Si le problème suit le port, c’est le port/chemin. S’il suit le disque entre ports, c’est le disque.

Cinquième étape : stabilisez puis scrubez/resilver

• Corrigez d’abord le problème physique/chemin. Resilverer via un lien instable est la manière de transformer un petit incident en week-end prolongé.

Signatures dans les logs qui distinguent disque vs lien vs contrôleur

Le noyau est verbeux quand SATA se comporte mal. Cette verbosité est votre amie, si vous apprenez les phrases communes.
Ci‑dessous des patterns que je traite comme indicateurs « probables », pas comme absolus.

Boucle classique de réinitialisation de lien

Cherchez des séquences répétées comme : exception Emask → hard resetting link → SATA link up → répétition.
Quand cela arrive sous charge, ZFS voit des timeouts et des erreurs d’I/O ; vos applications voient des pics de latence et des échecs « aléatoires ».

CRC et erreurs de transport (câble/backplane/chemin)

Les indicateurs incluent une montée de UDMA_CRC_Error_Count, SError: { CommWake }, et des erreurs qui disparaissent après une réinitialisation du lien.
Les compteurs média restent souvent stables. Le disque dit : « Je peux stocker des bits ; je n’arrive juste pas à parler pour l’instant. »

Timeouts de commande avec NCQ

Des messages comme failed command: READ FPDMA QUEUED peuvent traduire soit un problème de lien soit un bug de firmware du disque.
Votre désambiguïsation dépend de la répétabilité et de la corrélation : si plusieurs disques montrent la même chose sur le même contrôleur, accusez le chemin.

Signature d’échec média disque

Cela tend à montrer une augmentation de Reallocated_Sector_Ct, Current_Pending_Sector,
Offline_Uncorrectable, et des erreurs de checksum ZFS qui se concentrent sur un seul périphérique indépendamment du port.

Signature de défaillance au niveau contrôleur

Quand un HBA ou un contrôleur intégré est en cause, vous voyez souvent des réinitialisations affectant plusieurs disques attachés dans une fenêtre temporelle restreinte.
ZFS peut dégrader plusieurs vdevs simultanément. Ce n’est pas de la « malchance ». C’est un destin partagé.

Une idée paraphrasée souvent attribuée à Jim Gray : Les défaillances sont normales ; les systèmes doivent supposer que les composants tombent en panne et se rétablissent automatiquement.
ZFS suppose cela. Votre câblage SATA probablement pas.

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

Le but ici n’est pas de mémoriser des commandes. C’est de transformer « disque tombé » en une décision structurée :
remplacer le disque, remplacer le câble, remplacer le HBA, changer l’alimentation, ou ajuster les paramètres du noyau.
Chaque tâche ci‑dessous inclut : commande, sortie exemple, ce que cela signifie, et ce que vous faites ensuite.

Task 1: Get the ground truth from ZFS

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Thu Dec 26 01:10:02 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-ST8000VN004-2M2101   DEGRADED    12     0     0  too many errors
            ata-ST8000VN004-2M2101   ONLINE      0     0     0
errors: No known data errors

Ce que cela signifie : ZFS a vu des erreurs de lecture sur un périphérique (READ=12). L’absence d’erreurs de checksum signifie que les lectures ont échoué au niveau du transport, pas « des données corrompues retournées ».

Décision : Ne remplacez pas encore le disque. Allez consulter les logs du noyau et SMART. Les erreurs couche-transport sentent la réinitialisation de lien.

Task 2: Map ZFS device names to physical paths

cr0x@server:~$ ls -l /dev/disk/by-id | grep ST8000VN004 | head
lrwxrwxrwx 1 root root  9 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF -> ../../sdc
lrwxrwxrwx 1 root root 10 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF-part1 -> ../../sdc1

Ce que cela signifie : Le disque problématique est actuellement /dev/sdc.

Décision : Utilisez /dev/sdc pour SMART et pour cartographier le port du contrôleur.

Task 3: Pull kernel messages around the event

cr0x@server:~$ sudo journalctl -k --since "2025-12-26 00:50" --until "2025-12-26 01:30" | egrep -i "ata[0-9]|reset|link|SError|I/O error" | tail -n 25
Dec 26 01:03:12 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 01:03:12 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 26 01:03:12 server kernel: ata7: SError: { RecovComm Persist PHYRdyChg CommWake DevExch }
Dec 26 01:03:13 server kernel: ata7: hard resetting link
Dec 26 01:03:18 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:03:18 server kernel: ata7.00: configured for UDMA/133
Dec 26 01:03:19 server kernel: sd 6:0:0:0: [sdc] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 01:03:19 server kernel: blk_update_request: I/O error, dev sdc, sector 912345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Dec 26 01:03:25 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 26 01:03:25 server kernel: ata7: hard resetting link

Ce que cela signifie : C’est une tempête de réinitialisations de lien. Les phrases clés sont « interface fatal error », « hard resetting link », et des drapeaux SError comme PHYRdyChg.

Décision : Traitez d’abord comme câble/backplane/contrôleur. Déplacez le disque ou changez le câble SATA/la voie du backplane avant de resilver.

Task 4: Check SMART for media vs transport indicators

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature"
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       42110
194 Temperature_Celsius     0x0022   108   098   000    Old_age   Always       -       42
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   197   000    Old_age   Always       -       54

Ce que cela signifie : Pending/uncorrectable sont à zéro : le média paraît sain. Les erreurs CRC sont non nulles et augmentent souvent quand le câblage/backplane est marginal.

Décision : Changez le câble/emplacement de backplane, resseyez les connecteurs, inspectez pour des coudes serrés et des tensions. Suivez si le compteur CRC augmente après les modifications.

Task 5: Confirm the controller/port mapping for the disk

cr0x@server:~$ sudo ls -l /sys/block/sdc/device | head -n 5
lrwxrwxrwx 1 root root 0 Dec 26 01:25 driver -> ../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Dec 26 01:25 scsi_device -> ../../../../bus/scsi/devices/6:0:0:0
lrwxrwxrwx 1 root root 0 Dec 26 01:25 subsystem -> ../../../../bus/scsi
lrwxrwxrwx 1 root root 0 Dec 26 01:25 target6:0:0 -> ../../../../bus/scsi/targets/6:0:0

Ce que cela signifie : Nous sommes en traduction SCSI (normal pour du SATA derrière libata). Ensuite, mappez vers ata7 (depuis les logs) et le périphérique PCI.

Décision : Identifiez quel contrôleur et quel port sont responsables afin de pouvoir changer le bon câble ou déplacer la charge loin d’un contrôleur instable.

Task 6: Identify the SATA/AHCI controller PCI device

cr0x@server:~$ sudo lspci -nnk | egrep -A3 -i "sata|ahci"
00:17.0 SATA controller [0106]: Intel Corporation C620 Series Chipset Family SATA Controller [AHCI mode] [8086:a282]
        Subsystem: Supermicro Computer Inc Device [15d9:0888]
        Kernel driver in use: ahci
        Kernel modules: ahci

Ce que cela signifie : AHCI Intel onboard. Pas intrinsèquement mauvais, mais le traitement des erreurs et l’isolation des ports peuvent être moins bons qu’un HBA dédié dans certaines combinaisons châssis/backplane.

Décision : Si vous observez des réinitialisations multi-disques répétées sur ce contrôleur, pensez à migrer les disques vers un HBA reconnu pour sa gestion d’erreurs.

Task 7: Inspect link speed and negotiated state

cr0x@server:~$ sudo dmesg -T | egrep -i "ata7: SATA link|configured for UDMA" | tail -n 5
[Thu Dec 26 01:03:18 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 01:03:18 2025] ata7.00: configured for UDMA/133

Ce que cela signifie : Le lien négocie à 6.0 Gbps. Si vous voyez des rétrogradations fréquentes (à 3.0 ou 1.5), c’est un gros indice de problèmes de signal.

Décision : Si la stabilité s’améliore en forçant 3.0 Gbps (atténuation temporaire), traitez-le comme un problème de couche physique et planifiez des corrections matérielles.

Task 8: Check ZFS error counters per device over time

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz2-0                   DEGRADED     0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-ST8000VN004-...       DEGRADED    12     0     0  too many errors

Ce que cela signifie : Erreurs READ mais pas de CKSUM. Si CKSUM commence à augmenter, vous pourriez avoir des données corrompues (ou des lectures de secteurs décalées) plutôt que de simples timeouts.

Décision : Erreurs READ uniquement : concentrez-vous sur les réinitialisations/timeouts du lien. Erreurs de CKSUM : risque d’intégrité—accélérez la remédiation et envisagez de retirer le périphérique s’il empoisonne les lectures.

Task 9: Clear errors after you fix the path (so you can see if it returns)

cr0x@server:~$ sudo zpool clear tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool status -v tank | egrep -A2 "ata-ST8000VN004|READ|WRITE|CKSUM"
            ata-ST8000VN004-2M2101_ZA1ABCDF  ONLINE       0     0     0

Ce que cela signifie : Les compteurs sont réinitialisés. Maintenant, les nouvelles erreurs sont réellement nouvelles, pas de l’historique ancien.

Décision : Surveillez. Si les erreurs reviennent rapidement, vous n’avez pas corrigé la cause racine.

Task 10: Run a targeted SMART self-test (after stabilizing)

cr0x@server:~$ sudo smartctl -t short /dev/sdc
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
cr0x@server:~$ sudo smartctl -l selftest /dev/sdc | head -n 8
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     42111         -

Ce que cela signifie : Les diagnostics internes du disque n’ont pas trouvé de problème média évident.

Décision : Renforce l’hypothèse « problème de chemin ». Si les auto-tests échouent avec des erreurs de lecture, reconsidérez le disque.

Task 11: Scrub after remediation to confirm integrity

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | egrep -i "scan|scrub|errors"
  scan: scrub in progress since Thu Dec 26 02:10:01 2025
        1.23T scanned at 1.10G/s, 210G issued at 187M/s, 20.1T total
        0B repaired, 1.02% done, no estimated completion time
errors: No known data errors

Ce que cela signifie : Le scrub lit tout ; si le lien est encore instable, c’est généralement là qu’on le verra.

Décision : Si des réinitialisations réapparaissent pendant le scrub, vous avez toujours un problème de transport. Arrêtez et réparez le matériel ; ne « scrubez » pas plus fort.

Task 12: Watch for recurring link resets live during load

cr0x@server:~$ sudo dmesg -wT | egrep -i "ata7|hard resetting link|I/O error|SError"
[Thu Dec 26 02:14:22 2025] ata7: hard resetting link
[Thu Dec 26 02:14:27 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Ce que cela signifie : Le problème se produit encore en direct. C’est une bonne nouvelle : les bugs reproductibles se fixent.

Décision : Interrompez tout resilver/scrub en cours, resseyez/remplacez le câble, et envisagez de déplacer le disque vers un autre contrôleur pour confirmer la corrélation de chemin.

Task 13: Check if multiple disks share the same pain (controller/backplane suspect)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "hard resetting link|COMRESET failed|SATA link down" | awk '{print $(NF-1),$NF}' | tail
link up
link
link up
link
link up

Ce que cela signifie : Pas super lisible, mais l’idée est : comptez les réinitialisations et voyez si elles impliquent plusieurs ports ataX.

Décision : Si vous voyez plusieurs ports ata se réinitialiser ensemble, cessez d’accuser des disques individuels. Commencez à suspecter le contrôleur, l’alimentation, le backplane, l’expander ou des EMI au niveau châssis.

Task 14: Verify ZFS sees physical IDs stably (avoid surprise renames)

cr0x@server:~$ sudo zpool status -P tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-...  ONLINE  0 0 0
            /dev/disk/by-id/ata-ST8000VN004-...   DEGRADED 12 0 0

Ce que cela signifie : L’utilisation de chemins by-id aide quand l’ordre /dev/sdX change après des réinitialisations ou des reboots.

Décision : Si votre pool utilise des noms bruts /dev/sdX, planifiez une fenêtre de maintenance pour migrer vers des identifiants persistants (ou assurez‑vous au moins que l’OS utilise un nommage stable).

Task 15: Replace a device correctly when it really is the disk

cr0x@server:~$ sudo zpool offline tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool replace tank ata-ST8000VN004-2M2101_ZA1ABCDF /dev/disk/by-id/ata-ST8000VN004-2M2101_ZA9NEWID
cr0x@server:~$ sudo zpool status tank | egrep -i "resilver|scan|state"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 03:01:10 2025

Ce que cela signifie : Workflow correct pour remplacer : offline → replace → surveiller le resilver.

Décision : Ne faites cela qu’après que le lien soit stable. Resilverer sur un lien instable est la recette pour fabriquer des « erreurs de checksum mystérieuses » qui coûtent des jours.

Blague n°2 : Resilverer à travers un mauvais câble SATA, c’est comme opérer pendant un tremblement de terre—techniquement possible, émotionnellement inutile.

Causes racines : les suspects habituels avec détails production

Câbles : les coupables silencieux

Les câbles SATA sont bon marché, ce qui est bien jusqu’à ce que vous réalisiez que le mode de défaillance est intermittent. Le câble peut assurer une connectivité de base,
fonctionner correctement en faible charge, et ne lâcher qu’en cas de lectures à haute profondeur de queue, scrubs ou resilvers.
Un câble peut aussi être « correct » jusqu’à ce que vous fermiez le châssis ou modifiiez le flux d’air et qu’il commence à toucher un carter de ventilateur.

Que faire : Remplacez par des câbles courts et de qualité ; évitez les coudes serrés ; assurez-vous que les connecteurs s’enclenchent ; gardez les câbles à l’écart des zones à forte vibration.
Si vous avez un backplane, le « câble » inclut le connecteur du backplane et ses cycles d’emmanchement. Ressemer n’est pas de la superstition ; c’est de la maintenance.

Backplanes : intégrité du signal et connecteurs usés

Les backplanes ajoutent de la commodité et du hot-swap, mais ajoutent aussi des connecteurs, des traces, et parfois une mise à la terre douteuse.
Un connecteur légèrement oxydé peut se comporter comme un générateur de nombres aléatoires selon la température.
Certains backplanes sont excellents. D’autres sont « acceptables » jusqu’à ce que vous les utilisiez en 6Gb/s avec certains disques et un certain contrôleur.

Que faire : Changez le disque pour un autre emplacement ; si l’erreur reste liée à l’emplacement, vous avez trouvé la voie du backplane.
Si votre châssis le permet, bypassez temporairement le backplane avec un câble direct pour prouver le point.

Contrôleurs AHCI intégrés : suffisants jusqu’à ce qu’ils ne le soient plus

Beaucoup de systèmes utilisent les SATA intégrés pendant des années. Le problème survient quand quelque chose casse.
Certains contrôleurs récupèrent proprement d’un glitch de lien ; d’autres déclenchent des tempêtes, bloquent des ports, ou réinitialisent plusieurs liens ensemble.
Sous ZFS, ce comportement devient coûteux opérationnellement : un glitch momentané se transforme en erreurs vdev et dégradation de pool.

Que faire : Pour du stockage sérieux, utilisez un HBA dédié avec une bonne gestion d’erreurs et un firmware stable.
Si vous devez utiliser l’intégré, gardez le firmware à jour, évitez les gestions d’alimentation agressives, et surveillez les réinitialisations corrélées multi-disques.

Alimentation : la catégorie « ce n’est pas l’alim » qui est souvent l’alim

Les disques consomment un courant significatif au démarrage et lors de certaines opérations. Des PSU marginaux, des répartiteurs surchargés,
ou des connecteurs d’alimentation lâches peuvent provoquer des chutes de tension momentanées. Les réinitialisations de lien peuvent être le symptôme poli ; le symptôme impoli est un disque qui disparaît.

Que faire : Éliminez les répartiteurs, utilisez des feeds d’alimentation de backplane appropriés, vérifiez la santé des PSU, et évitez d’alimenter trop de disques depuis un même harnais.
Si les réinitialisations se corrèlent au démarrage moteur (spin-up) ou à des pics d’I/O, remettez l’alimentation sur la liste des suspects.

Thermique et vibration : l’environnement riposte

Les variations de température affectent la résistance des contacts et les marges de signal. La vibration affecte l’assise et la qualité du contact.
Un châssis avec des ventilateurs haut régime et un paquet de câbles SATA tendus est essentiellement un petit banc d’essai mécanique.

Que faire : Améliorez la gestion des câbles, utilisez des connecteurs verrouillables, assurez une bonne tenue des caddies disques, et stabilisez le flux d’air.
Si les erreurs surviennent après un remplacement de ventilateur ou un changement de flux d’air, considérez cela comme un indice, pas une coïncidence.

ALPM/HIPM/DIPM et la gestion d’alimentation « utile »

La gestion d’alimentation du lien peut provoquer des transitions que du matériel marginal ne supporte pas. Vous verrez des patterns étranges : l’inactivité est correcte,
puis un pic de trafic déclenche une réinitialisation ; ou l’inverse—actif correct, mais inactif entraîne des coupures.

Que faire : Envisagez de désactiver les gestions d’alimentation agressives du lien pour les systèmes de stockage, surtout si vous avez déjà observé des réinitialisations.
Il ne s’agit pas de courir après des points de benchmark ; il s’agit de garder le bus ennuyeux.

Interactions de firmware : mort par matrice de compatibilité

Les disques ont des bizarreries de firmware. Les contrôleurs ont des bizarreries de firmware. Les backplanes ont parfois des expanders avec leurs propres bizarreries.
Mettez-les ensemble et vous obtenez des comportements émergents. Le pire type de bug est celui qui disparaît quand vous changez un numéro de pièce.

Que faire : Standardisez. Gardez les HBA en mode IT quand c’est approprié, maintenez le firmware cohérent, et évitez de mélanger trop de modèles de disques dans un même châssis si possible.
Quand vous trouvez une combinaison stable, documentez-la et protégez-la contre le « juste un disque différent ».

Trois mini-histoires du monde de l’entreprise (anonymisées, plausibles et douloureusement familières)

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

Une entreprise SaaS de taille moyenne exploitait une paire de serveurs de stockage avec des vdevs en miroir ZFS. Ils recevaient des alertes occasionnelles : un disque tombait,
revenait, et ZFS journalisait quelques erreurs de lecture. L’équipe a supposé « le disque est en train de mourir » parce que c’est l’histoire commune dans le monde courant.
Ils ont remplacé le disque. Deux semaines plus tard, un autre disque dans le même châssis a fait la même chose.

Ils ont remplacé ce disque aussi. Après le troisième « disque défaillant » en un mois, les achats se sont impliqués, des tickets fournisseurs ont été ouverts,
et des réunions ont eu lieu. Pendant ce temps, le vrai signal était discrètement dans l’attribut SMART 199 : les UDMA CRC montaient sur plusieurs disques,
mais seulement ceux connectés à une moitié du backplane.

La mauvaise hypothèse était subtile : ils croyaient que les pannes de disque sont indépendantes et aléatoires. Dans le stockage ZFS, les pannes corrélées comptent plus que les individuelles.
Quand plusieurs « mauvais disques » apparaissent sur le même chemin physique, vous regardez une infrastructure partagée.

La réparation fut ennuyeuse : remplacer l’ensemble de câbles SATA affecté et resseoir les connecteurs du backplane pendant une fenêtre de maintenance.
Les « disques défaillants » qu’ils avaient retirés ? La plupart ont passé les diagnostics du fournisseur. L’équipe a appris à la dure que remplacer des pièces sans isoler les variables
n’est que de la devinette coûteuse avec un meilleur éclairage.

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

Un groupe d’analytique de données voulait réduire la consommation et la chaleur dans un rack dense. Ils ont activé une gestion d’alimentation SATA agressive
et ajusté des paramètres OS pour permettre aux disques et liens de descendre plus souvent en états basse consommation. Sur le papier, c’était raisonnable :
la charge était en rafales, et le temps d’inactivité abondait.

Deux mois plus tard, leurs fenêtres de scrub ZFS ont commencé à échouer. Pas systématiquement—juste assez pour être exaspérant.
Les scrubs déclenchaient une vague de hard resetting link sur certains ports, et le pool se dégradait. Les reboots « réglaient » le problème,
ce qui facilitait le mauvais diagnostic en bug logiciel.

Le retour de bâton provenait d’une combinaison d’intégrité du signal marginale et de transitions fréquentes d’état d’alimentation.
Le système était stable quand les liens restaient up. Il était instable quand les liens basculaient entre états toute la journée.
L’optimisation a augmenté le nombre de transitions, et donc le nombre d’occasions d’atteindre le cas limite.

Ils ont annulé les réglages agressifs et les réinitialisations ont cessé. Plus tard, ils ont amélioré le câblage et remplacé un backplane suspect,
puis ont réintroduit une gestion d’alimentation plus douce, prudemment. La leçon n’était pas « ne jamais optimiser ». C’était « n’optimisez pas un système que vous n’avez pas rendu robuste ».

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

Une équipe IT d’entreprise exploitait ZFS pour du stockage VM. Ils avaient une habitude qui paraissait fastidieuse : chaque emplacement disque était étiqueté, chaque câble documenté,
et chaque disque était mappé depuis /dev/disk/by-id vers une baie physique et un port contrôleur. Ils gardaient aussi un petit stock de câbles connus bons.
Personne ne s’en vantait en réunion d’architecture.

Une nuit, un pool s’est dégradé pendant une forte charge de lecture. Les alertes incluaient des réinitialisations de lien et des timeouts. L’ingénieur de garde a lancé zpool status -P,
a récupéré le périphérique by-id, puis a consulté le doc de mapping : « Baie 12, port HBA 2, voie backplane B ». Ils n’ont pas deviné quel disque retirer.
Ils ont sorti le bon tiroir du premier coup.

Les données SMART montraient des erreurs CRC mais un média propre. Cela a orienté le diagnostic vers « problème de chemin ».
Ils ont déplacé le disque vers une baie de rechange sur une autre voie, ont effacé les erreurs, et ont repris les opérations. Le pool a guéri, et l’incident a cessé.
En journée, ils ont remplacé la voie du backplane et le câble suspect.

La pratique n’était pas glamour. Elle n’a pas augmenté le débit. Elle a amélioré le temps moyen pour retrouver la raison.
En production, « ennuyeux et correct » est une fonctionnalité, pas un défaut de caractère.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: ZFS shows READ errors, but SMART reallocated/pending are zero

Cause racine : Timeouts de transport et réinitialisations de lien, souvent câblage/backplane/contrôleur.

Fix : Vérifiez les logs du noyau pour les réinitialisations ; inspectez/remplacez le câble SATA ; déplacez le disque vers un autre port/emplacement ; suivez le compteur UDMA CRC avant/après.

2) Symptom: “hard resetting link” repeats during scrub/resilver

Cause racine : Intégrité du signal marginale qui ne cède que sous charge soutenue et profondeur de queue continue.

Fix : Arrêtez le scrub/resilver ; corrigez la couche physique d’abord. Après remédiation, relancez le scrub pour confirmer la stabilité.

3) Symptom: Multiple disks drop around the same timestamp

Cause racine : Réinitialisation de contrôleur partagée, problème d’alimentation backplane, défaillance d’expander/backplane, ou problème PSU/harnais d’alimentation.

Fix : Corrélez par contrôleur et alimentation ; inspectez le câblage d’alimentation ; envisagez la migration vers un meilleur HBA ; vérifiez la santé du backplane.

4) Symptom: CRC errors climb steadily, but performance seems fine

Cause racine : Le lien « fonctionne » via des retries. Vous payez la taxe de latence et risquez une escalade.

Fix : Remplacez préventivement le câble/l’emplacement. Les compteurs CRC ne sont pas décoratifs.

5) Symptom: After reboot, everything is “fine” for a while

Cause racine : Le reboot ressert le timing/état ; ne corrige pas la voie marginale. Il réinitialise aussi les compteurs et masque la tendance.

Fix : N’acceptez pas le reboot comme remède. Collectez les logs et SMART avant le reboot ; puis réparez le composant physique ou contrôleur.

6) Symptom: You replace the disk and the new disk “fails” in the same bay

Cause racine : Voie du backplane ou défaut de câble/connecteur.

Fix : Changez de baie/slot ; remplacez le câble ; inspectez le connecteur du backplane ; stoppez le churn RMA.

7) Symptom: ZFS checksum errors appear alongside link resets

Cause racine : Vous obtenez peut‑être des données corrompues retournées (ou des lectures décallées), pas seulement des timeouts ; pourrait être l’intégrité du chemin, le contrôleur, ou le firmware du disque.

Fix : Montez la sévérité. Assurez-vous que la redondance est intacte, scrubez après stabilisation, et envisagez de remplacer la totalité du chemin (contrôleur/backplane) plutôt que de courir après un seul câble.

8) Symptom: Errors only happen when the chassis is touched or during maintenance

Cause racine : Stress mécanique sur les connecteurs ; assise marginale ; tension des câbles ; verrouillage insuffisant.

Fix : Refaire la gestion des câbles avec du mou, utiliser des câbles verrouillables, resseoir les disques, et vérifier que les sleds/connecteurs du backplane ne sont pas usés.

Listes de contrôle / plan pas à pas

Étape par étape : contenir l’incident sans l’aggraver

1. Arrêtez les I/O lourds inutiles (mettez en pause scrubs/resilvers si le lien se réinitialise activement).
2. Collectez des preuves : zpool status -v, fenêtre journalctl -k, et smartctl -a pour les périphériques affectés.
3. Décidez disque vs chemin en utilisant SMART (média vs CRC) et les logs noyau (réinitialisations/timeouts).
4. Stabilisez le chemin : resseyez les deux extrémités ; remplacez le câble SATA ; essayez un autre slot backplane ; assurez-vous que le connecteur d’alimentation est solide.
5. Effacez les erreurs ZFS après remédiation pour que toute réapparition soit évidente.
6. Scrubez une fois stable pour valider l’intégrité et détecter d’éventuels maillons faibles restants.
7. Uniquement ensuite remplacez les disques qui montrent des indicateurs médias nets ou qui échouent aux auto-tests.

Checklist d’hygiène matérielle (faites-le avant d’être en feu)

• Utilisez des câbles SATA verrouillables ; évitez les « câbles mystère » provenant de boîtes aléatoires.
• Gardez les longueurs de câbles courtes et avec du mou ; pas de coudes serrés, pas de tension sur les connecteurs.
• Documentez le mapping baie → périphérique et le mapping port contrôleur.
• Standardisez les HBA et les firmwares ; évitez de mélanger des contrôleurs dans le même pool si possible.
• Validez la qualité du backplane pour le 6Gb/s ; traitez les slots usés comme consommables.
• N’excédez pas les harnais d’alimentation PSU ; évitez les répartiteurs bon marché en production.
• Planifiez les scrubs à des moments où vous pouvez observer leur impact ; les scrubs sont des diagnostics, pas que des corvées.

Checklist décisionnelle : remplacer quoi, exactement ?

• Remplacez le disque quand : les erreurs média montent, les auto-tests SMART échouent, les erreurs suivent le disque entre ports, ou ZFS montre des erreurs de checksum persistantes liées au disque.
• Remplacez le câble quand : les UDMA CRC montent, des réinitialisations de lien surviennent, ou le problème disparaît après échange de câble/mouvement.
• Remplacez/upgradez le contrôleur (HBA) quand : plusieurs ports se réinitialisent ensemble, la récupération d’erreur est médiocre, ou la stabilité s’améliore quand les disques sont déplacés vers un autre contrôleur.
• Remplacez la voie/ le backplane quand : les erreurs restent attachées à un slot indépendamment du disque, ou plusieurs disques sur le même segment backplane montrent des problèmes corrélés.
• Corrigez l’alimentation quand : les coupures se corrèlent au spin-up/pics de charge, plusieurs disques disparaissent, ou le même harnais alimente tous les disques affectés.

FAQ

1) Are SATA link resets always a failing disk?

Non. Souvent c’est le chemin qui lâche : câble, connecteur backplane, port contrôleur, ou alimentation. Utilisez SMART (CRC vs média) et les logs (boucles de reset) pour trancher.

2) What’s the single best SMART attribute for “bad cable” suspicion?

UDMA_CRC_Error_Count (attribut 199) est le signe classique. Ce n’est pas parfait, mais un CRC montant avec des compteurs média propres est un fort indice.

3) If CRC errors are non-zero, should I panic?

Non‑zéro signifie « quelque chose s’est passé à un moment ». Monter signifie « ça se passe maintenant ». La tendance compte. Effacez les erreurs ZFS, enregistrez les valeurs SMART, puis surveillez les augmentations.

4) Why does this show up during scrub/resilver more than normal workloads?

Le scrub/resilver est soutenu, large et implacable en I/O. Il augmente la profondeur de queue et exerce chaque bloc. Les liens marginaux lâchent sous une charge soutenue.

5) Can ZFS checksum errors be caused by SATA cabling?

Oui. Si le transport corrompt les données et que le disque/contrôleur ne l’attrape pas avant la livraison, ZFS le détectera par checksum. C’est ZFS qui fait son travail—et qui vous dit de réparer le chemin.

6) Should I disable NCQ to “fix” link resets?

Désactiver NCQ peut réduire la charge et parfois masquer un problème en changeant les timings, mais c’est généralement un contournement. Réparez le problème physique/contrôleur. Ne basez pas une stratégie de stockage sur des superstitions.

7) Why do errors sometimes vanish after moving cables around?

Parce que resseoir change la résistance de contact, l’alignement, et la contrainte mécanique. Si resseoir corrige, vous aviez un problème de connecteur/câble/backplane. Considérez cela comme un diagnostic, pas comme une solution définitive.

8) When should I replace the controller/HBA instead of chasing cables?

Quand vous voyez des réinitialisations corrélées sur plusieurs ports, une mauvaise récupération d’erreur, ou une instabilité qui suit le contrôleur plutôt qu’un disque. Aussi quand vous comptez sur un AHCI intégré pour des pools sérieux et qu’il se comporte mal.

9) Is it safe to resilver while link resets are happening?

C’est risqué. Vous prolongerez l’incident, augmenterez le stress sur le pool, et risquez de déclencher plus de fautes. Stabilisez le lien d’abord, puis resilver.

10) How do I prove it’s the backplane slot?

Insérez un disque connu bon dans ce slot et déplacez le disque suspect vers un autre slot. Si l’erreur reste avec le slot, vous avez une voie/connecteur backplane défaillant.

Prochaines étapes que vous pouvez réellement faire demain

Si vous observez des réinitialisations de lien SATA dans un système ZFS, votre travail est de rendre le chemin I/O à nouveau ennuyeux. ZFS s’occupera de l’intégrité,
mais il ne peut pas ressouder des connecteurs à votre place.

1. Basez vos preuves : capturez zpool status -v, les logs noyau autour du reset, et smartctl -a pour les disques affectés.
2. Classez : indicateurs média → disque ; CRC/boucles de reset → chemin ; réinitialisations multi-disques corrélées → contrôleur/alimentation/backplane.
3. Changez une chose à la fois : échangez le câble, déplacez le slot, changez de contrôleur. Confirmez que le problème suit le composant suspect.
4. Effacez et surveillez : réinitialisez les compteurs ZFS après remédiation ; observez si les erreurs reviennent lors d’un scrub.
5. Mettez à niveau le maillon faible : si vous exploitez du ZFS sérieux sur des SATA intégrés fragiles, migrez vers un HBA et un backplane/câblage fiables.

Le but n’est pas d’éliminer toutes les fautes. Le but est d’éliminer les fautes ambiguës—celles qui font perdre du temps, déclenchent des RMA inutiles, et menacent silencieusement la redondance.
Réparez le chemin, puis laissez ZFS faire le travail pour lequel vous l’avez choisi.