Réinitialisations de lien SATA sous Debian 13 : Prouvez que c’est le câble ou le backplane, pas Linux

octobre 14, 2025 • février 3, 2026 • Lecture : 30 min • Views: 9

Cet article vous a aidé ?

Certaines pannes ne commencent pas par une explosion. Elles commencent par un hoquet disque, un seul ataX: link is slow to respond, puis un effondrement au ralenti : reconstructions RAID, resilver ZFS, remontées de systèmes de fichiers en lecture seule, et une équipe qui se dispute pour savoir si « le nouveau noyau Debian » est responsable.

Si vous exploitez Debian 13 sur de vrais serveurs avec de vrais câblages SATA — backplanes, sortes d’expandeurs, câbles breakout bon marché, et un flux d’air qui va jusqu’au jour où il ne suffit plus — les réinitialisations de lien SATA sont un type de panne qui ressemble à un problème logiciel tant que vous n’avez pas prouvé que c’est matériel. Voici comment le prouver.

Ce qu’est réellement une réinitialisation de lien SATA (et ce que ce n’est pas)

Une « réinitialisation de lien SATA » est la tentative du contrôleur de rétablir le lien physique et protocolaire avec un disque. Linux le rapporte via libata (le sous-système du noyau qui gère ATA/SATA). Vous verrez des phrases comme :

link is slow to respond
COMRESET failed
hard resetting link
SATA link up 6.0 Gbps (après récupération)
ataX: device reported invalid CHS (souvent du bruit)
I/O error, dev sdX (le rayon d’impact visible par les applications)

Distinction importante : une réinitialisation de lien n’est pas la même chose qu’une erreur de média.

Erreur de média : le disque ne peut pas lire un secteur de manière fiable. Cela incrémente typiquement des attributs SMART comme « Reallocated_Sector_Ct » ou enregistre des erreurs de lecture.
Erreur de lien : le contrôleur et le disque ne parviennent pas à communiquer correctement. Cela incrémente souvent SMART « UDMA_CRC_Error_Count » et se manifeste par des réinitialisations/timeout. Les plateaux peuvent être sains ; la conversation ne l’est pas.

Linux ne « cause » pas la dégradation du signal électrique. Mais Linux sera absolument le messager, et il se fera blâmer. Votre travail est de séparer : (1) une régression du noyau, (2) un problème de contrôleur/firmware, (3) un disque en fin de vie, (4) un câble/backplane/chemin d’alimentation qui ne tient pas un lien stable.

Voici la réalité opérationnelle : si vous voyez des réinitialisations de lien répétées et des erreurs CRC sur une baie/port, remplacer le disque « répare » souvent le problème seulement parce que vous avez ré-assis le câble ou changé le schéma de vibrations. Ce n’est pas une réparation ; c’est gagner à la roulette.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Blague n°1 : Un câble SATA, c’est comme une invitation à une réunion — tout semble aller bien jusqu’à ce qu’il commence à perdre des paquets et que tout le monde blâme l’agenda.

Faits et contexte : pourquoi le SATA échoue de cette façon

Quelques points concrets et brefs qui vous aident à raisonner sur ce que vous voyez dans les logs Debian 13. Ce n’est pas de la trivia ; ça explique les modes de défaillance.

Le SATA est série, mais reste analogique en périphérie. Les bits voyagent sur un lien électrique sensible à l’impédance, au blindage, à l’usure des connecteurs et au diaphonie — surtout dans les backplanes denses.
COMRESET est une vraie poignée de main électrique. Quand vous voyez « COMRESET failed », l’hôte essaie de réinitialiser la couche PHY et ne reçoit pas de réponse propre. C’est souvent le câble/backplane, parfois l’alimentation, occasionnellement le contrôleur.
Les erreurs CRC SMART ont été conçues pour détecter les problèmes de câblage. « UDMA_CRC_Error_Count » s’incrémente quand le disque détecte des erreurs de transmission entre le disque et l’hôte. Les erreurs de média ne l’incrémentent pas.
NCQ a rendu le SATA plus rapide et le débogage plus difficile. Native Command Queuing permet plusieurs commandes simultanées. Quand le lien est instable, les échecs ressemblent à des timeouts dans une file, pas à des « secteurs illisibles » propres.
Les connecteurs SATA grand public ne sont pas conçus pour des cycles d’insertion infinis. Un backplane qui a vu des années de swaps de disques s’use : la tension des ressorts change, l’oxydation apparaît, le plastique se déforme avec la chaleur.
Beaucoup de « backplanes SATA » sont en fait passifs jusqu’à ce qu’ils cassent. Certains ont des multiplexeurs, des ré-timeurs, des LED ou des connecteurs bon marché qui se comportent bien à 1,5 Gbps et deviennent chaotiques à 6,0 Gbps.
La récupération d’erreur de libata sous Linux est agressive par conception. Elle essaie des hard resets, soft resets, rétrogradation de vitesse et revalidation. C’est bon pour la disponibilité et mauvais pour le doigt-pointing.
La rétrogradation de la vitesse de lien est un signal indubitable. Un port qui négocie de 6.0 à 3.0 ou 1.5 Gbps sous charge indique fréquemment un problème d’intégrité du signal, pas un bug système de fichiers.
Les vibrations et la chaleur comptent plus qu’on ne l’admet. Une connexion à peine marginale peut échouer seulement pendant un pic d’I/O (plus d’EMI, plus de chaleur) ou lors d’un changement de profil des ventilateurs.

Playbook de diagnostic rapide (premier/second/troisième)

Vous êtes en astreinte. L’ensemble est dégradé. L’application timeoute. Vous avez besoin du chemin le plus rapide vers « que remplaçons-nous, et qu’est-ce qu’on cesse de toucher ? » Voici ce chemin.

Premier : confirmez que c’est de l’instabilité au niveau du lien, pas simplement un disque mourant

Scannez journalctl/dmesg pour hard resetting link, COMRESET, failed command: READ FPDMA QUEUED, link up/down.
Vérifiez SMART UDMA_CRC_Error_Count (ou le journal PHY SATA si disponible). S’il augmente, considérez le câblage/backplane comme suspect principal.
Vérifiez si les réinitialisations suivent une baie/port, pas un numéro de série de disque.

Second : corrélez les erreurs à un seul port/baie sous charge

Mappez /dev/sdX → ataX → port HBA → baie physique.
Cherchez les changements de vitesse de lien et les réinitialisations répétées sur le même ataX.
Exécutez un test de lecture contrôlé sur ce disque seulement, et surveillez les logs en direct.

Troisième : isolez le domaine de faute avec des swaps qui vous apprennent quelque chose

Remplacez le câble/chemin backplane avant de changer l’OS ou de « tuner le noyau ». Déplacez le disque dans une autre baie ; si les erreurs restent avec la baie, vous avez votre coupable.
Remplacez par un câble connu bon (ou un autre connecteur backplane) et relancez le même test de charge.
Ce n’est qu’après que le câblage/backplane/alimentation soient écartés que vous passez au firmware, aux pilotes du contrôleur ou aux régressions du noyau.

Cet ordre n’est pas idéologique. C’est mathématique : les défauts de câblage et de backplane sont fréquents, rapides à tester, et ils n’apparaissent pas dans votre pipeline CI.

Votre standard de preuves : construire un dossier qui résiste au post-mortem

Si vous voulez arrêter la boucle « Linux l’a fait », vous avez besoin d’une chaîne de preuves reproductible :

Chronologie : horodatages exacts des réinitialisations et des erreurs I/O.
Identité : quel disque (WWN et numéro de série), quel ataX, quel port HBA, quelle baie.
Type de signal : CRC/lien/poignée de main vs réallocation média vs bug de contrôleur.
Reproductibilité : un test qui déclenche l’erreur (ou ne la déclenche pas) dans des conditions contrôlées.
Résultat du swap : l’erreur suit la baie/câble/backplane (chemin matériel) ou suit le disque (périphérique).

Une mise à jour du noyau peut changer le timing suffisamment pour révéler un lien marginal. Ça ne veut pas dire que le noyau « a cassé le SATA ». Ça veut dire que le noyau a cessé de marcher sur la pointe des pieds autour de votre couche physique défaillante.

Tâches pratiques : commandes, sorties, ce qu’elles signifient, et ce que vous décidez

Ce sont de vraies tâches que vous pouvez exécuter sur Debian 13. Chacune inclut : une commande, une sortie d’exemple, ce que cela signifie, et la décision à en tirer. N’exécutez pas de tests de stress sur un ensemble de production sans coordination ; le « chaos contrôlé » reste du chaos.

Task 1: Pull a focused SATA/libata error timeline from the journal

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "ata[0-9]+|sata|hard reset|link up|link down|comreset|i/o error|exception"
Dec 29 10:11:02 server kernel: ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 10:11:02 server kernel: ata7: SError: { CommWake 10B8B DevExch }
Dec 29 10:11:02 server kernel: ata7: hard resetting link
Dec 29 10:11:03 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 29 10:11:03 server kernel: ata7.00: configured for UDMA/133
Dec 29 10:11:04 server kernel: blk_update_request: I/O error, dev sde, sector 124518400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Signification : Emask 0x10 et les indicateurs SErr avec un hard reset suggèrent fortement un événement de transport/lien. L’erreur I/O est un dommage collatéral.

Décision : Traitez ceci comme une instabilité de lien jusqu’à preuve du contraire. Étape suivante : identifier quel disque est sde et vérifier ses compteurs CRC SMART.

Task 2: Confirm which disk is sde (serial, WWN, model)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,HCTL /dev/sde
NAME SIZE MODEL            SERIAL         WWN                HCTL
sde  12T  ST12000NM0008-2A ZS2ABC12       0x5000c500cafe1234 3:0:6:0

Signification : Vous avez maintenant des identifiants stables (numéro de série/WWN) et un chemin HCTL.

Décision : Utilisez WWN/numéro de série dans les tickets et post-mortems, pas /dev/sde. Les noms de périphérique bougent ; les WWN ne bougent pas (généralement).

Task 3: Read SMART attributes; look specifically for CRC errors vs media errors

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
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   200   000    Old_age   Always       -       47

Signification : Le média semble propre (pas de reallocations/pending). Les erreurs CRC sont non nulles. Les erreurs CRC sont presque toujours des problèmes de câblage/backplane/chemin contrôleur, pas la surface du disque.

Décision : Arrêtez de remplacer les disques « parce qu’ils échouent ». Concentrez-vous sur le lien : câble, connecteur backplane, port HBA, et alimentation vers cette baie.

Task 4: Check whether CRC errors are still increasing

cr0x@server:~$ sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

cr0x@server:~$ sleep 60; sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       49

Signification : Il est passé de 47 à 49 en une minute. C’est un problème de transport actif.

Décision : Escaladez pour intervention physique. Planifiez une fenêtre de maintenance si l’ensemble est redondant ; sinon, considérez cela comme un risque d’incident imminent.

Task 5: Watch kernel messages live while you do a controlled read

cr0x@server:~$ sudo dmesg -Tw
[Sun Dec 29 10:21:17 2025] ata7: hard resetting link
[Sun Dec 29 10:21:18 2025] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[Sun Dec 29 10:21:18 2025] ata7.00: configured for UDMA/133

cr0x@server:~$ sudo dd if=/dev/sde of=/dev/null bs=4M status=progress iflag=direct
12582912000 bytes (13 GB, 12 GiB) copied, 7 s, 1.8 GB/s

Signification : Le lien est revenu à 3.0 Gbps au lieu de 6.0. Cette rétrogradation est un classique « l’intégrité du signal s’est dégradée sous charge ».

Décision : Marquez le chemin baie/port comme suspect. Planifiez le remplacement du câble/connexion backplane pour ce port. Ne perdez pas de temps à tuner les ordonnanceurs d’I/O.

Task 6: Identify the libata “ata7” mapping in sysfs

cr0x@server:~$ readlink -f /sys/class/block/sde/device
/sys/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0

Signification : Vous pouvez lier le périphérique bloc à un port ATA spécifique (ata7) et un hôte.

Décision : Utilisez ce chemin pour trouver le périphérique PCI du contrôleur et, à partir de là, l’emplacement du slot/HBA/chaîne backplane.

Task 7: Confirm the controller PCI identity and driver

cr0x@server:~$ lspci -nnk | egrep -A3 -i "sata|ahci|scsi|sas"
00:1f.2 SATA controller [0106]: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller [8086:3a22]
	Subsystem: Supermicro Computer Inc Device [15d9:0801]
	Kernel driver in use: ahci
	Kernel modules: ahci

Signification : Vous êtes sur AHCI (SATA intégré courant). Si c’était une HBA, vous verriez mpt3sas, megaraid_sas, etc.

Décision : Si c’est du SATA intégré avec un long chemin de backplane bon marché, supposez une fragilité physique jusqu’à preuve du contraire.

Task 8: Verify link speed and negotiated features (where available)

cr0x@server:~$ sudo grep -H . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link6/sata_spd: 3.0 Gbps
/sys/class/ata_link/link7/sata_spd: 6.0 Gbps

Signification : Au moins un lien est à 3.0 Gbps. Si vos disques et contrôleur supportent 6.0, cela peut être une rétrogradation de vitesse négociée après des erreurs.

Décision : Traitez une rétrogradation soutenue sur le port problématique comme une preuve. Incluez-la dans vos notes d’incident ; c’est convaincant pour les non-spécialistes du noyau.

Task 9: Inspect per-disk error counters and kernel “timeout” patterns

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "failed command|READ FPDMA|WRITE FPDMA|cmd|timeout|resetting"
Dec 29 10:21:16 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 29 10:21:16 server kernel: ata7.00: cmd 60/08:00:00:10:6e/00:00:00:00:00/40 tag 0 ncq dma 4096 in
Dec 29 10:21:16 server kernel: ata7.00: status: { DRDY }
Dec 29 10:21:16 server kernel: ata7: softreset failed (1st FIS failed)
Dec 29 10:21:17 server kernel: ata7: hard resetting link

Signification : « FIS failed » et les timeouts de commande avec réinitialisations sont cohérents avec une défaillance de transport, pas « le système de fichiers qui s’énerve ».

Décision : Isolez en déplaçant le disque dans une autre baie ou en changeant le câble. Les actions purement logicielles n’arrêteront pas la physique.

Task 10: Check if the drive is actually being power-cycled (power path/backplane)

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "rejecting i/o|device offline|Spinning|Start/Stop|Power-on|reset"
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] rejecting I/O to offline device
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00

Signification : « offline device » peut survenir d’une perte de lien, mais s’il est accompagné de messages répétés de « nouveau disque », suspectez des interruptions d’alimentation ou un comportement du backplane.

Décision : Si vous voyez des cycles remove/add, priorisez les connecteurs d’alimentation du backplane et la stabilité des rails PSU. Les réinitialisations de lien plus la disparition du périphérique sont une alarme plus forte.

Task 11: Verify drive identity is stable across resets (same WWN comes back)

cr0x@server:~$ udevadm info --query=all --name=/dev/sde | egrep "ID_WWN=|ID_SERIAL=|DEVPATH="
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0/block/sde
E: ID_SERIAL=ST12000NM0008-2A_ZS2ABC12
E: ID_WWN=0x5000c500cafe1234

Signification : Vous pouvez confirmer que la même identité revient après une réinitialisation. Si l’identité change ou disparaît, vous avez peut-être un multiplexeur backplane instable ou un problème de contrôleur.

Décision : Identité stable + CRC croissant pointe vers la qualité du lien physique plutôt que vers un comportement étrange du firmware du disque.

Task 12: If you run mdadm, confirm whether the array is dropping the same member repeatedly

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

Signification : (F) indique un membre failed. Si le même emplacement continue d’échouer, c’est rarement « Linux RAID est instable » ; c’est le lien sous-jacent.

Décision : Ne ré-ajoutez pas sans cesse le même disque sans traiter le transport. Vous brûlerez des cycles de rebuild et augmentez le risque d’un second défaut.

Task 13: If you run ZFS, see whether errors are checksum or I/O-level, and which vdev

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: Replace the device using 'zpool replace'.
  scan: resilver in progress since Sun Dec 29 10:30:01 2025
config:

	NAME                        STATE     READ WRITE CKSUM
	tank                        DEGRADED     0     0     0
	  raidz2-0                  DEGRADED     0     0     0
	    wwn-0x5000c500cafe1234  DEGRADED     5     0     0  too many errors
	    wwn-0x5000c500beef5678  ONLINE       0     0     0
	    wwn-0x5000c500abcd9999  ONLINE       0     0     0
	    wwn-0x5000c5001234aaaa  ONLINE       0     0     0

Signification : ZFS montre des erreurs READ sur un WWN spécifique. C’est cohérent avec des réinitialisations de lien causant des échecs I/O (pas nécessairement des erreurs de checksum silencieuses).

Décision : Si CKSUM est zéro et READ non-zéro avec des réinitialisations libata, ce n’est probablement pas une corruption silencieuse — ce sont des lectures échouées dues à des pertes de lien. Réparez le transport d’abord, puis remplacez/nettoyez.

Task 14: Check drive temperature and error log to rule out overheating-induced instability

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "Temperature|Error Log|ATA Error Count"
194 Temperature_Celsius     0x0022   037   045   000    Old_age   Always       -       63
SMART Error Log Version: 1
ATA Error Count: 0

Signification : 63°C est élevé pour beaucoup de disques SATA d’entreprise. Ça peut encore « fonctionner », mais les marges de signal diminuent avec la chaleur et les backplanes se déforment.

Décision : Améliorez le refroidissement et retestez. Si les erreurs n’apparaissent qu’à chaud, ne déclarez pas victoire après un test en chambre froide.

Mapper /dev/sdX vers un port physique sans deviner

La façon la plus rapide de perdre toute crédibilité est d’extraire le mauvais disque. La deuxième plus rapide est de « réinsérer des câbles » de façon générique et d’appeler ça terminé. Cartographiez.

Utilisez des identifiants stables : WWN, numéro de série, HCTL et ataX

Commencez par WWN/numéro de série depuis lsblk ou udevadm. Ensuite, reliez-les à :

HCTL (Host:Channel:Target:Lun) pour l’énumération de type SCSI (courant pour les HBAs)
ataX pour la numérotation des ports libata (courant pour AHCI et de nombreux chemins SATA)
chemin PCI pour trouver le contrôleur réel

Sur beaucoup de serveurs, le maillon manquant est l’étiquetage physique des baies. La solution correcte n’est pas la « connaissance tribale ». C’est la documentation : une carte de ports du port HBA → connecteur backplane → numéros de baie.

Approche pratique de cartographie quand vous n’avez pas de plan de ports

Identifiez le disque défaillant par WWN/numéro de série.
Trouvez son DEVPATH et l’association ataX.
Corrélez ataX au connecteur carte mère/HBA en vérifiant les schémas de câblage, le manuel du châssis, ou en retraçant physiquement pendant une fenêtre.
Validez en déplaçant seulement ce disque dans une autre baie et en vérifiant si les erreurs suivent la baie.

La dernière étape compte parce qu’elle convertit la « suspicion éclairée » en preuve.

Schémas matériels : comment les câbles et backplanes s’incriminent

Quand les gens blâment Linux, ils réagissent généralement à une corrélation : « on a mis à jour Debian, puis les disques ont commencé à se réinitialiser. » Cette corrélation est réelle. Elle signifie juste autre chose que ce qu’ils pensent.

Voici les schémas qui séparent de manière fiable les domaines de faute.

Schémas de panne liés au câble

Les erreurs CRC augmentent (attribut SMART 199) tandis que les secteurs réalloués/en attente restent stables.
Les erreurs corrèlent avec la vibration ou le mouvement : choc du châssis, montée des ventilateurs, mouvement d’un faisceau de câbles voisin.
Le problème suit la connexion câble/backplane : déplacer le disque dans une autre baie le corrige sans remplacer le disque.
La vitesse du lien se rétrograde vers 3.0/1.5 Gbps sur ce port après des réinitialisations.

Que faire : remplacez le câble par un câble connu bon, idéalement plus court et mieux blindé ; évitez les coudes serrés ; réacheminez loin des faisceaux d’alimentation quand possible. Si c’est un Mini-SAS vers SATA breakout, considérez-le comme consommable.

Schémas de panne de backplane

Une seule baie est maudite, indépendamment du modèle ou du numéro de série du disque.
La présence du disque clignote : le système note la disparition et la réapparition du disque.
Plusieurs disques sur le même segment backplane montrent des erreurs après une hausse de température ou un événement de vibration.
Comportement LED/SGPIO anormal : LED d’activité bloquées ou mauvais clignotement de baies peut corréler à un problème de signal ou de masse sur des backplanes bon marché.

Que faire : déplacez le disque dans une baie différente comme test ; si la baie est coupable, remplacez le backplane ou cessez d’utiliser cet emplacement. « Nettoyer les contacts » n’est pas un plan sauf si vous contrôlez aussi la récurrence par remplacement.

Schémas de panne liés à l’alimentation

Réinitialisations simultanées sur plusieurs ports, souvent après une montée en charge (pics CPU, montée des ventilateurs, spin-up des disques).
Réinitialisations coïncidant avec des alarmes PSU ou des chutes de tension signalées par le BMC.
Les disques enregistrent des événements liés à l’alimentation (selon le modèle ; souvent pas explicite).

Que faire : vérifiez l’état des PSU, le câblage d’alimentation vers le backplane, et si un spin-up étagé est configuré. Un PSU « bon » peut être mauvais en réponse transitoire.

Schémas de panne contrôleur/firmware

Les erreurs se propagent sur de nombreux ports sans corrélation à une baie unique.
Réinitialisations déclenchées par des patrons de commande spécifiques (TRIM, profondeur NCQ, écritures mises en file) et disparaissent avec des mises à jour de driver/firmware.
Les logs du noyau montrent des réinitialisations du contrôleur, pas seulement des réinitialisations de lien.

Que faire : vérifiez les versions de firmware ; testez avec une autre HBA si possible. Mais n’utilisez pas « contrôleur peut-être » pour ignorer les preuves CRC.

Schémas de panne disque

Les secteurs réalloués/en attente augmentent, SMART santé échoue, les auto-tests échouent.
Les erreurs suivent le disque jusqu’à une baie et un câble connus bons.
Le journal d’erreurs SMART montre des échecs de lecture/écriture sans croissance correspondante des CRC.

Que faire : remplacez le disque, et n’argumentez pas avec les chiffres.

Blague n°2 : Si votre stockage « ne tombe en panne qu’en charge », félicitations — vous avez conçu un système parfaitement fiable quand il est inactif.

Trois mini-histoires d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « C’est le nouveau noyau Debian »

L’environnement était ordinaire : une paire de boîtes Debian exécutant une base de données répliquée, chacune avec quelques SSD SATA dans un châssis hot-swap frontal. Une mise à jour routine a installé un noyau plus récent, et en l’espace d’un jour un nœud a commencé à lancer des réinitialisations ata. L’équipe a fait ce que font les équipes : elle a reverti le noyau.

Les erreurs ont diminué, mais pas cessé. C’était le premier indice. Le second indice était plus vilain : l’autre nœud a commencé à montrer des réinitialisations occasionnelles aussi. Le récit est passé de « régression du noyau » à « peut-être que le firmware du SSD n’aime pas Linux ». Un ticket fournisseur a été ouvert. Du temps a été passé à rassembler des traces noyau qui disaient à tout le monde ce qu’ils savaient déjà : le lien était réinitialisé.

Ce qui a finalement rompu la boucle fut une corrélation disciplinée. Un SRE a comparé les UDMA_CRC_Error_Count pour chaque disque du châssis. Seuls les disques des baies 5–8 avaient des CRC en hausse. Ces baies partageaient un connecteur backplane et une course de câble breakout. La mise à jour n’était pas la cause ; c’était le moment où le système est devenu suffisamment occupé pour exposer une connexion marginale.

La « réparation » fut ennuyeuse : remplacer le câble breakout et réassoir le connecteur backplane. Puis relancer la même charge qui déclenchait auparavant les réinitialisations. Les erreurs ne sont pas revenues. Le noyau est resté mis à jour. Le post-mortem fut gênant parce que la mauvaise hypothèse n’était pas stupide ; elle était plausible. Mais la plausibilité n’est pas une preuve, et la production ne vous paie pas pour du plausible.

2) L’optimisation qui a eu l’effet inverse : « On va augmenter la profondeur de queue pour économiser de l’argent »

Une flotte analytique intensive en stockage était optimisée pour le débit. Quelqu’un avait lu que des files plus profondes et plus de parallélisme améliorent l’utilisation. Ils ont augmenté la concurrence I/O dans l’application et ajusté aussi quelques paramètres de la couche bloc pour garder les disques occupés. Les premiers benchmarks étaient excellents. Tout le monde s’est félicité et est passé à autre chose.

Deux semaines plus tard, un sous-ensemble d’hôtes a commencé à voir sporadiquement des échecs READ FPDMA QUEUED et des réinitialisations de lien. Les échecs se concentraient pendant les fenêtres de batch. L’équipe a traité ça comme un problème de charge et a étalé les jobs, ce qui a aidé. C’était le piège : le système devenait stable seulement quand il était moins utile.

La cause racine s’est révélée physique. Le châssis utilisait de longs câbles SATA routés à côté de faisceaux d’alimentation à fort courant. À faible I/O, les marges du lien étaient à peine acceptables. À grande profondeur de file, les disques et le contrôleur travaillaient plus, le profil thermique changeait, et le taux d’erreur du lien montait — jusqu’à ce que libata commence à réinitialiser les ports. Rien de « mystique » n’est arrivé ; ils ont simplement déplacé un système de « fonctionne au labo » vers « échoue à l’échelle » en s’appuyant sur des marges de signal fines.

L’action corrective n’a pas été d’abandonner l’optimisation de performance. Ce fut de traiter le câblage comme une part de l’enveloppe de performance : câbles plus courts, routage propre, et dans quelques cas migrer des charges intensives vers des HBAs SAS avec de meilleurs connecteurs. Après cela, le même tuning n’a plus déclenché de réinitialisations. L’optimisation n’était pas le méchant. Optimiser sur du matériel bancal l’était.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : une vraie carte de ports et des identifiants cohérents

Une autre organisation exploitait un stockage mixte : du mdadm, du ZFS, plein de baies hot-swap. Ils avaient l’habitude qui paraissait presque démodée : chaque châssis avait une carte de ports dans le runbook. Elle listait les numéros de port HBA, les références des câbles, les étiquettes de connecteur backplane, et la plage de baies que chaque connecteur servait. Ils enregistraient aussi les WWN des disques dans l’inventaire quand les disques étaient installés.

Un après-midi, un hôte a commencé à loguer des réinitialisations de lien sur un disque. L’astreinte a suivi le playbook : identifier le WWN, mapper au port HBA, mapper à la baie. Ils n’ont pas extrait des disques au hasard. Ils n’ont pas reboot « pour nettoyer ». Ils n’ont pas downgrade un noyau. Ils ont déplacé le disque vers une baie de secours sur le même hôte et répété le test de lecture. Les erreurs sont restées avec la baie d’origine.

Avec cela, la remédiation fut précise : le connecteur backplane pour ce groupe de baies a été remplacé pendant une fenêtre planifiée. Le disque est resté en service et n’a jamais montré d’erreurs média. Le ticket fut court et convaincant parce qu’ils avaient les reçus : CRC en hausse, corrélation baie, et un swap d’isolation réussi.

C’est la partie que les gens n’aiment pas : le débogage « héroïque » était inutile parce que les travaux ennuyeux existaient. La documentation n’a fait sentir personne intelligent, mais elle a rendu le système moins cher à exploiter. C’est le travail.

Erreurs courantes : symptômes → cause racine → correctif

Ceci est ce qui maintient des incidents plus longtemps qu’ils ne le méritent.

1) Symptom: repeated `hard resetting link` + rising CRC errors

Cause racine : trajet de signal SATA marginal (câble, connecteur, backplane).
Fix : remplacer le câble/chemin backplane ; réacheminer ; éviter les coudes serrés ; retester sous charge ; vérifier que le compteur CRC cesse d’augmenter.

2) Symptom: disk drops out entirely and comes back as “new”

Cause racine : interruption d’alimentation à la baie/backplane, ou détection de présence backplane instable.
Fix : inspecter/remplacer les connecteurs d’alimentation du backplane ; vérifier l’état du PSU ; vérifier la contrainte sur les faisceaux d’alimentation partagés ; valider les logs BMC.

3) Symptom: errors “move” after you swap drives

Cause racine : vous avez ré-assis ou perturbé le câble/connecteur défaillant, améliorant temporairement le contact.
Fix : arrêtez de prétendre que c’est réparé ; exécutez un test de charge contrôlé et surveillez les compteurs CRC ; remplacez de toute façon le câble suspect.

4) Symptom: link negotiates down to 1.5/3.0 Gbps after resets

Cause racine : rétrogradation suite à la récupération d’erreur due à une faible intégrité du signal.
Fix : traitez comme un problème de couche physique ; remplacez câble/backplane ; confirmez qu’il reste à 6.0 Gbps sous charge soutenue.

5) Symptom: “Linux I/O scheduler change fixed it”

Cause racine : vous avez réduit l’intensité I/O, masquant le problème.
Fix : conservez le scheduler si ça aide, mais remplacez quand même le lien marginal. Les défauts cachés reviennent quand vous avez besoin de performance.

6) Symptom: ZFS/mdadm rebuilds keep restarting on same disk

Cause racine : transport instable provoquant des échecs I/O transitoires pendant des lectures/écritures séquentielles lourdes.
Fix : réparez le lien d’abord ; ensuite relancez le rebuild une seule fois. Les storms de rebuild sont la façon de transformer un chemin flou en outage.

7) Symptom: kernel upgrade “triggered” the issue

Cause racine : la charge, le timing ou le profil de puissance ont suffisamment changé pour exposer un chemin marginal ; le noyau est un catalyseur, pas la cause.
Fix : conservez la mise à jour à moins de pouvoir reproduire sur l’ancien noyau et prouver une régression ; concentrez-vous sur les preuves physiques (CRC, corrélation baie).

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

Checklist de réponse incident (tant que le système est dégradé)

Capturez les logs : journalctl -k autour de l’événement. Sauvegardez-les quelque part de durable.
Enregistrez l’identité du disque : modèle, numéro de série, WWN, HCTL, et mapping ataX.
Vérifiez SMART pour distinguer média vs CRC. Si le CRC augmente, élevez le câblage/backplane.
Réduisez le rayon d’impact : suspendez les jobs lourds non essentiels ; évitez les tentatives de rebuild répétées.
Si redondance, planifiez un swap d’isolation contrôlé (déplacer le disque dans une autre baie).
Après changement physique, exécutez le même test de lecture et surveillez les logs en direct.
Vérifiez les compteurs : le CRC doit cesser d’augmenter ; le lien doit rester à la vitesse attendue.

Plan de fenêtre de maintenance (quoi remplacer et dans quel ordre)

Remplacez le câble SATA/breakout desservant le port/groupe de baies défaillant.
Si les échecs persistent et suivent la baie, remplacez/réparez le segment backplane ou cessez d’utiliser la baie.
Validez l’alimentation : réassiez les connecteurs d’alimentation du backplane ; contrôlez l’état du PSU ; vérifiez l’absence de brownouts sous charge.
Ce n’est qu’ensuite qu’il faut envisager des mises à jour firmware du contrôleur ou remplacer la HBA/carte mère SATA.
Exécutez un burn-in de lecture/écriture soutenu sur les disques affectés après les changements.

Checklist post-incident de durcissement (prévenir la suite)

Créez une carte de ports : port HBA → étiquette câble → connecteur backplane → numéros de baies.
Standardisez l’usage de noms basés WWN dans les configs ZFS/mdadm quand possible.
Suivez les compteurs SMART CRC dans le temps ; alertez sur les deltas, pas seulement sur des seuils absolus.
Gardez des câbles connus bons de rechange et, si possible, un backplane de rechange en stock.
Documentez une procédure d’isolation pour que le prochain astreint n’improvise pas.

FAQ

1) Does a SATA link reset always mean the drive is bad?

Non. Souvent le disque est sain et le lien ne l’est pas. Si SMART montre une augmentation de UDMA_CRC_Error_Count avec des attributs média propres, suspectez d’abord le câble/backplane.

2) If SMART overall-health says PASSED, can the disk still be the problem?

Oui. Le « PASSED » SMART n’est pas une garantie ; c’est un contrôle faible. Mais pour les cas de réinitialisation de lien, le discriminateur est généralement CRC vs secteurs réalloués/en attente.

3) Why did this start right after upgrading Debian 13?

Parce que le timing, la gestion d’énergie ou le profil de charge ont changé. Une mise à jour du noyau peut modifier les schémas I/O et exposer du matériel marginal. Traitez la mise à jour comme un déclencheur, pas comme une preuve de causalité.

4) Can bad power cause CRC errors?

Indirectement. L’instabilité d’alimentation peut provoquer des pertes de lien et des réinitialisations de périphérique, et le comportement résultant peut ressembler à un problème de transport. Si les disques disparaissent et réapparaissent, investiguez la puissance et les circuits de présence du backplane.

5) Is it safe to keep running if CRC errors are non-zero but stable?

Si le compteur CRC est ancien et n’augmente pas, vous pourriez avoir un événement historique (un câble a été heurté une fois). S’il augmente, vous perdez activement l’intégrité du lien et devez corriger rapidement.

6) How do I prove it’s the backplane and not the disk?

Déplacez le même disque (même WWN/numéro de série) dans une autre baie/chemin de câble. Si les erreurs cessent, l’ancien chemin/baie est coupable. Si les erreurs suivent le disque, le disque est coupable.

7) Why do I see link speed drop to 3.0 Gbps?

Après des erreurs, le SATA peut renégocier à une vitesse inférieure pour maintenir la stabilité. C’est un signe de qualité de signal marginale. Ce n’est pas une « fonctionnalité de performance ».

8) Should I change kernel parameters or libata settings to reduce resets?

Évitez d’utiliser des paramètres noyau comme pansement sauf si vous diagnostiquez un problème confirmé de pilote/contrôleur. Si les preuves physiques pointent vers le lien, changer les timeouts ne fait que modifier le délai avant l’échec.

9) What if multiple disks across different bays show CRC increases?

Suspectez quelque chose de partagé : un faisceau de câbles, un connecteur backplane alimentant plusieurs baies, un groupe de ports HBA, ou l’alimentation. Cherchez la communauté, pas la coïncidence.

10) Do I need SAS to avoid this?

Pas strictement, mais les connecteurs et câblages SAS sont généralement plus robustes en environnements serveurs. Le SATA peut être fiable ; il exige simplement plus de discipline sur la couche physique que ne le fournissent de nombreux châssis.

Conclusion : prochaines étapes qui réduisent réellement le risque

Si Debian 13 logue des réinitialisations de lien SATA, traitez-le comme une enquête, pas comme un débat. Linux vous dit ce qu’il voit. Votre travail est de déterminer si le problème vit sur les plateaux, dans le contrôleur, ou dans le cuivre et le plastique que tout le monde oublie d’examiner.

Faites ceci ensuite, dans l’ordre :

Tirez une chronologie serrée des logs noyau et capturez les preuves.
Vérifiez SMART : CRC vs attributs média. Si le CRC bouge, arrêtez de blâmer les systèmes de fichiers.
Mappez le périphérique défaillant à ataX/HCTL et à une baie physique.
Exécutez un test de lecture contrôlé en surveillant dmesg en direct.
Isolez avec un swap qui vous apprend quelque chose : déplacez le disque dans une autre baie ou remplacez le chemin de câble.
Après la réparation, vérifiez : vitesse de lien stable, CRC qui n’augmente plus, et absence de réinitialisations sous charge.

Si vous ne retenez qu’une leçon opérationnelle : écrivez la carte de ports et suivez les deltas CRC. Ce n’est pas glamour, mais ça transforme un « problème de stockage Linux » effrayant en un simple remplacement de pièce avec reçus.