Votre pool ZFS va bien. Jusqu’à ce qu’il ne l’est plus. Vous lancez un scrub ou un resilver, la latence passe de « ennuyeuse » à « épicée »,
et dmesg commence à raconter un désastre : timeouts de commande, réinitialisations de lien, et des disques qui disparaissent juste assez longtemps
pour gâcher votre journée et votre confiance.
Beaucoup de gens tirent de ces incidents une conclusion simple : « le SAS est stable ; le SATA est capricieux. »
Ce n’est pas faux, mais ce n’est pas toute l’histoire non plus. La vraie différence se situe dans la sémantique des timeouts, le comportement de récupération d’erreurs,
les couches de transport et la réaction des HBAs sous contrainte. ZFS est le messager. Ne le blâmez pas.
Ce que « stable » signifie réellement dans l’univers ZFS
Quand les opérateurs disent que le SAS « paraît plus stable », ils veulent généralement dire :
- Les disques ne disparaissent pas du système pendant les scrubs/resilvers.
- La gestion des erreurs est bornée : les défaillances apparaissent comme des erreurs, pas comme des blocages de plusieurs minutes.
- Les contrôleurs se rétablissent proprement sans réinitialiser des liens entiers ou des bus complets.
- La latence reste suffisamment prévisible pour que ZFS maintienne le pool sain sans paniquer.
ZFS est allergique au silence. Si un vdev cesse de répondre assez longtemps, ZFS suppose qu’il est parti et le marque en défaut.
Parfois le disque est « correct » au sens consommateur — pas de secteurs réalloués, SMART indique OK — mais il a passé 45 secondes
à faire de la récupération d’erreurs en profondeur. ZFS ne fait pas dans l’empathie ; il exige que les E/S se terminent dans les délais.
« Stable » signifie donc souvent : la pile de stockage échoue vite et échoue étroitement.
Le SAS a tendance à être conçu dans cet esprit. Le SATA est souvent optimisé pour le coût au To et une attente de type poste de travail :
une longue pause est acceptable si elle permet de sauver un secteur.
Timeouts 101 : l’échec que vous voyez vs l’échec que vous avez
Un timeout dans les logs est rarement la cause racine. C’est le point où l’OS cesse d’attendre. La véritable cause appartient à l’une de ces familles :
- Problèmes média : secteurs faibles/instables qui déclenchent de longues tentatives internes.
- Problèmes de transport : erreurs de lien, câbles marginaux, problèmes de backplane, expanders « dramatiques ».
- Problèmes de contrôleur : bugs de firmware HBA, famine de queues, réinitialisations sous tempêtes d’erreurs.
- Pression de la charge : scrubs/resilvers + lectures aléatoires + petites écritures sync entrent en collision et la file devient un parking.
En pratique, le SAS « gagne » sous contrainte parce que son écosystème suppose que vous exécutez un backplane de stockage partagé,
avec multipath, des expanders, des dizaines de disques, et des équipes opérationnelles prêtes à remplacer un disque plutôt que de le supplier de réessayer pendant deux minutes.
Le SATA peut être fiable, mais il faut être plus strict : meilleure alimentation, meilleurs câbles/backplanes, firmware à jour, et des disques configurés pour une récupération d’erreur bornée (si supporté).
Sans cela, vous obtenez le mode d’échec classique de ZFS : un disque fait une pause, le HBA se réinitialise, quelques autres disques subissent des dommages collatéraux, et ZFS pense que le monde s’écroule.
Comportements SAS vs SATA importants sous stress ZFS
Error recovery philosophy: bounded vs “let me cook”
Les disques SAS d’entreprise sont typiquement réglés pour des environnements RAID : si la lecture d’un secteur échoue, ne passer pas un temps infini.
Retourner une erreur rapidement pour que la couche de redondance (RAID, miroir ZFS/RAIDZ) puisse reconstruire et réécrire. Ce n’est pas de l’altruisme ; c’est de la survie. Dans un array partagé, un disque bloqué peut bloquer beaucoup d’autres.
Beaucoup de disques SATA — spécialement les modèles desktop/NAS légers — vont s’acharner à récupérer un secteur en interne. Cela peut signifier
des dizaines de secondes de boucles de retry. Pendant ce temps, le disque peut ne pas répondre à d’autres commandes. Du point de vue de l’OS, le périphérique est « figé ».
La réponse entreprise ici est TLER/ERC/CCTL (différents vendeurs, même concept) : limiter le temps que le disque passe en récupération avant de renvoyer une erreur.
Les disques SAS se comportent souvent comme si cela était toujours activé.
Les disques SATA peuvent ne pas le supporter, l’avoir désactivé par défaut, ou se comporter de façon incohérente selon les versions de firmware.
Transport and command handling: SAS is SCSI-native; SATA is a translation party
Le SAS est un transport SCSI. Le SATA est ATA. Lorsque vous connectez des disques SATA derrière un HBA/backplane SAS, vous utilisez généralement
le SATA Tunneling Protocol (STP). Ça fonctionne, mais ce n’est pas équivalent au SAS de bout en bout :
certains rapports d’erreur sont moins expressifs, certaines voies de récupération sont moins propres, et sous de fortes erreurs de conditions vous pouvez
voir des réinitialisations de lien qui semblent disproportionnées pour un seul mauvais secteur.
Le SAS vous offre aussi des avantages comme le dual-porting (sur de nombreux disques) et une meilleure intégration avec multipath.
Cela compte quand l’objectif est « continuer à servir » plutôt que « terminer la lecture éventuellement ».
Queuing and fairness: who gets to talk, and how long
Sous charge, la pile de stockage est un système d’ordonnancement en file. Les infrastructures SAS (HBAs, expanders, firmware) sont généralement
conçues pour des files plus profondes et une meilleure équité entre de nombreux périphériques. Le SATA peut gérer NCQ, mais l’écosystème de bout en bout
est plus variable — surtout quand vous introduisez des port multipliers, des backplanes bon marché ou des contrôleurs grand public.
Votre scrub/resilver est un parfait test de torture de profondeur de file : lectures soutenues quasi-séquentielles plus recherches de métadonnées
plus écritures occasionnelles. Si un périphérique commence à retarder les complétions, les files se remplissent, des timeouts apparaissent et des réinitialisations se produisent.
Reset blast radius: SAS tends to be surgical; SATA can be “reset the universe”
Quand un périphérique SAS se comporte mal, la gestion d’erreur reste souvent limitée à ce périphérique ou à ce phy. Avec le SATA derrière STP, la récupération peut nécessiter
de réinitialiser un lien qui héberge aussi d’autres disques sur le même chemin backplane, ou au moins interrompre momentanément le trafic d’une façon qui cause des timeouts collatéraux.
Voilà pourquoi la même charge peut produire un comportement « un disque défaillant » en SAS et « trois disques ont disparu pendant 10 secondes »
en SATA dans le même châssis. Ce n’est pas de la magie. C’est la taille du domaine de reset.
SMART and telemetry: SAS tends to tell you more, sooner
Les périphériques SAS exposent des pages de log SCSI plus riches et souvent un reporting plus cohérent des défauts croissants et des compteurs d’erreurs.
SMART SATA est célèbre pour ses attributs vendor-specific et son « tout va bien jusqu’à ce que ça ne va plus ». Vous pouvez quand même opérer correctement avec du SATA,
mais il faut compenser par un meilleur suivi de tendance et des critères de remplacement plus stricts.
Première blague (parce que vous méritez une pause) : la récupération d’erreur SATA, c’est comme un micro-ondes qui n’arrête pas parce qu’il est « presque fini ». Vous finissez quand même par manger une pizza froide à 2h du matin.
Comment les scrubs/resilvers ZFS amplifient les maillons faibles
ZFS est un système de fiabilité qui effectue beaucoup d’E/S volontairement. Les scrubs lisent tout pour valider les checksums.
Les resilvers lisent beaucoup pour reconstruire la redondance. Les deux sont des tâches en arrière-plan qui ressemblent dangereusement à un benchmark
quand votre pool est assez grand.
Cela crée deux effets :
-
Vous touchez enfin les données froides. Le secteur qui se dégrade silencieusement depuis un an est lu.
Si le disque décide d’effectuer une récupération étendue, vous obtenez de longs blocages de commandes juste au moment où le pool est chargé. -
Vous concentrez le stress. Un resilver peut marteler un sous-ensemble de disques (ceux du vdev affecté)
et transformer une marginalité de lien/câble en erreurs répétées.
ZFS a aussi une opinion sur les périphériques lents. Si un périphérique est manquant ou non réactif assez longtemps, ZFS le mettra en défaut
pour garder le pool cohérent. C’est le comportement correct. La pile de stockage ne devrait pas bloquer indéfiniment.
Le piège de l’opérateur est d’interpréter « ZFS a mis le disque en défaut » comme « le disque est mort ». Parfois il est mort. Parfois le disque est correct mais votre transport est mauvais.
Parfois le disque est « correct » isolément mais inadapté à un array redondant parce qu’il bloque trop longtemps.
Faits et contexte historique (ce que l’on réapprend sans cesse)
- Fait 1 : Le SAS a été conçu comme successeur série lointain du SCSI parallèle avec des backplanes multi-périphériques et des expanders en tête ; « beaucoup de disques, un HBA » a toujours été le plan.
- Fait 2 : Le design initial du SATA visait le stockage desktop/commodity ; de longues retries internes étaient acceptables si elles récupéraient un fichier sans intervention utilisateur.
- Fait 3 : Le concept TLER/ERC/CCTL est apparu parce que les arrays RAID matériels avaient besoin que les disques échouent vite pour que le contrôleur reconstruise depuis la parité/les miroirs.
- Fait 4 : Le SATA derrière des backplanes SAS utilise couramment STP, un pont protocolaire qui peut réduire la fidélité de la gestion d’erreurs comparé au SAS natif.
- Fait 5 : Le SAS supporte le dual-porting sur de nombreux disques d’entreprise, permettant la redondance multipath ; le SATA ne le fait généralement pas (avec quelques exceptions de niche).
- Fait 6 : Le scrub de ZFS a été conçu pour détecter et corriger en continu la corruption silencieuse ; il génère volontairement une charge de lecture que d’autres systèmes de fichiers ne produisent pas par défaut.
- Fait 7 : Les incidents « disque disparu sous charge » se tracent souvent aux domaines de reset : une réinitialisation de contrôleur peut faire clignoter plusieurs périphériques SATA sur un chemin partagé.
- Fait 8 : L’industrie a passé des années à apprendre que « SMART dit OK » n’est pas une garantie ; les timeouts et les aborts de commande peuvent précéder tout seuil SMART.
- Fait 9 : Les écosystèmes SAS d’entreprise valident typiquement les combinaisons de firmware (HBA + expander + disque) plus rigoureusement car le marché exige un comportement de défaillance prévisible.
Trois mini-récits d’entreprise issus du terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne a déplacé un dépôt d’artefacts de build sur une nouvelle machine ZFS. Le design semblait raisonnable : RAIDZ2, beaucoup de disques SATA haute capacité bon marché, un HBA SAS populaire en mode IT, et un châssis 24 baies propre. Quelqu’un a demandé : « On devrait acheter des disques SAS ? » Quelqu’un d’autre a répondu : « Non, ZFS a des checksums. Ça ira. »
Le premier mois fut ennuyeux. Puis un scrub est tombé pendant une journée CI chargée. La latence a grimpé. Un disque a commencé à timeout.
Le HBA a tenté de récupérer avec des réinitialisations de lien. Deux autres disques SATA sur des baies voisines ont glitché assez longtemps pour déclencher des timeouts aussi. ZFS a mis un disque en défaut, puis a temporairement marqué un autre comme indisponible, et le pool est devenu dégradé avec une bonne dose de panique.
La mauvaise hypothèse n’était pas « le SATA est peu fiable ». La mauvaise hypothèse était « les fonctionnalités d’intégrité des données éliminent les problèmes de transport et de timeout ». Les checksums détectent la corruption. Ils ne forcent pas un disque à répondre rapidement.
La correction n’était pas exotique. Ils ont échangé les plus mauvais éléments contre des disques de classe entreprise avec comportement de récupération d’erreur borné, remplacé un câble de backplane suspect, et ajusté la planification des scrubs hors des heures de pointe. Plus important : ils ont écrit une règle opérationnelle : tout disque qui timeoute pendant un scrub est traité comme suspect jusqu’à preuve du contraire.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une autre équipe voulait des resilvers plus rapides. Leur idée : augmenter les profondeurs de queue, accroître le parallélisme, et laisser le HBA « s’étendre ». Ils ont augmenté des tunables, activé un comportement de scrub agressif, et fêté la victoire après un test rapide sur un pool vide.
Six semaines plus tard un disque est réellement tombé en panne. Le resilver a démarré sur un pool qui servait aussi des sauvegardes de base de données.
Les nouveaux réglages ont poussé les disques dans de longues files d’attente. La latence a atteint le plafond. Un disque SATA marginal qui était « correct » a commencé à accumuler des timeouts de commande. Le HBA a réagi par des réinitialisations, et le resilver a ralenti de toute façon — sauf que maintenant le pool était dégradé et instable.
Le post-mortem fut sans détour : optimiser pour la vitesse maximale de rebuild sans protéger de la marge de latence, c’est jouer avec votre fenêtre de redondance. Les rebuilds ne sont pas des benchmarks ; ce sont des procédures d’urgence.
Ils ont rétabli les tunables, limité l’impact scrub/resilver, et ont mesuré le succès par « le pool reste en ligne et la latence reste bornée », pas par le débit MB/s brut. Le resilver a mis plus longtemps. L’entreprise a subi moins de pannes. Le compromis s’est avéré pertinent.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société de services financiers exécutait ZFS sur des disques SAS avec une culture de maintenance stricte. Rien d’héroïque : firmware HBA connu et sain, modèles de disques cohérents, scrubs planifiés, et l’habitude simple de vérifier les compteurs d’erreurs chaque semaine. Ils faisaient aussi quelque chose de peu tendance : étiqueter chaque câble et noter quelle baie correspond à quel /dev.
Un trimestre, un scrub a rapporté une poignée d’erreurs de checksum et un seul périphérique avec des erreurs de transport en hausse.
Pas de panne. Pas de tickets. Juste des preuves silencieuses.
L’astreinte a remplacé un câble pendant une fenêtre de maintenance et a remplacé de manière proactive le disque qui montrait une augmentation du nombre de défauts croissants. Le scrub suivant était propre.
Deux mois plus tard, un rack voisin a eu un événement d’alimentation qui a causé une brève onde de réinitialisations de lien. Leur système est resté opérationnel.
Pourquoi ? Parce que l’hygiène « ennuyeuse » signifiait qu’il n’y avait pas de liaisons marginales prêtes à transformer un transitoire en cascade.
La stabilité opérationnelle, c’est surtout l’absence de surprises, et les surprises aiment les câblages négligés.
Feuille de route de diagnostic rapide
Quand ZFS lance des timeouts, vous n’avez pas de temps pour de la danse interprétative. Il faut trouver le goulot et le domaine de reset rapidement.
First: Confirm what ZFS thinks is happening
- Le pool est-il dégradé ? Quel vdev ?
- Les erreurs sont-elles des erreurs de checksum (corruption de données) ou des erreurs E/S/timeouts (périphérique/transport) ?
- Le problème est-il localisé à un disque ou plusieurs disques derrière le même HBA/backplane ?
Second: Correlate with kernel logs and identify the transport layer
- Recherchez les timeouts SCSI, aborts, task management resets, réinitialisations de lien.
- Identifiez le pilote : mpt2sas/mpt3sas, megaraid_sas, ahci, ata_piix, etc.
- Vérifiez si les périphériques affectés sont SAS ou SATA derrière STP.
Third: Measure latency and queue pressure during the event
- Utilisez
zpool iostat -vpour trouver le vdev lent. - Utilisez des métriques de latence par disque (
iostat -x) pour repérer quel disque se bloque. - Vérifiez si le HBA se réinitialise de façon répétée (signe de problèmes de transport/firmware ou d’un disque qui empoisonne le bus).
Fourth: Decide whether to quarantine the disk or fix the path
- Si un disque montre des timeouts répétés et beaucoup d’erreurs média : remplacez-le.
- Si plusieurs disques du même chemin backplane clignotent ensemble : inspectez/remplacez câbles, expander/backplane, firmware HBA.
- Si les problèmes n’apparaissent que pendant scrub/resilver : limitez l’agressivité de rebuild et planifiez ces tâches hors-pointe ; enquêtez quand même sur le composant faible sous-jacent.
Deuxième blague (dernière) : un disque qui « ne plante que pendant les scrubs » est comme un parachute qui « ne rate que pendant les sauts ». Ce n’est pas la brochure le problème.
Tâches pratiques (commandes, sorties et décisions)
Les commandes ci-dessous supposent un hôte Linux. Si vous utilisez illumos ou FreeBSD, les concepts se traduisent ; les noms de fichiers et les outils changent.
Les sorties montrées sont représentatives — votre machine aura son propre drame.
Task 1: Check pool health and error type
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 in progress since Thu Dec 26 01:11:19 2025
3.21T scanned at 812M/s, 1.94T issued at 492M/s, 12.8T total
0B repaired, 15.15% done, 0:07:21 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 3
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/backups/db/full-2025-12-25.sql.zst
Ce que cela signifie : Les erreurs de checksum signifient que ZFS a détecté des données qui ne correspondent pas à leur checksum. Cela peut être
un mauvais secteur, un câble défaillant, une RAM défectueuse ou un problème de contrôleur — mais ce n’est pas seulement un symptôme de timeout.
Décision : Si des erreurs de checksum sont présentes, traitez cela comme un incident d’intégrité des données. Identifiez les fichiers affectés, validez les sauvegardes, puis partez à la chasse de la cause matérielle.
Task 2: Watch per-vdev latency during scrub/resilver
cr0x@server:~$ sudo zpool iostat -v tank 2
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 8.44T 4.18T 2.40K 112 520M 5.12M
raidz2-0 8.44T 4.18T 2.40K 112 520M 5.12M
ata-WDC_WD140EDFZ-... - - 410 19 86.9M 862K
ata-WDC_WD140EDFZ-... - - 12 18 512K 840K
ata-WDC_WD140EDFZ-... - - 398 18 84.2M 835K
ata-WDC_WD140EDFZ-... - - 401 19 85.1M 860K
ata-WDC_WD140EDFZ-... - - 395 19 83.7M 858K
ata-WDC_WD140EDFZ-... - - 404 19 85.4M 865K
-------------------------- ----- ----- ----- ----- ----- -----
Ce que cela signifie : Un disque effectue presque aucune lecture alors que les autres travaillent. C’est un signe classique de
périphérique bloqué ou de problème de chemin. Décision : Identifiez le nom de périphérique OS de ce disque et inspectez les logs et SMART.
S’il se répète, prévoyez un remplacement ou une correction du chemin.
Task 3: Confirm which /dev node maps to the ZFS disk ID
cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD140EDFZ | head
lrwxrwxrwx 1 root root 9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 -> ../../sdb
lrwxrwxrwx 1 root root 9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC2 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC3 -> ../../sdd
Ce que cela signifie : ZFS affiche des noms by-id ; vous avez besoin du périphérique noyau pour SMART, les logs d’erreur, et le mapping contrôleur.
Décision : Utilisez by-id de manière cohérente dans ZFS, mais mappez vers /dev/sdX pour le triage.
Task 4: Pull kernel errors around the timeouts
cr0x@server:~$ sudo journalctl -k -S "2025-12-26 01:00" -g "timeout|reset|I/O error|mpt3sas|ata"
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 CDB: Read(16) 88 00 00 00 00 1b 2f 9e 80 00 00 00 01 00 00 00
Dec 26 01:13:44 server kernel: ata9: hard resetting link
Dec 26 01:13:45 server kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:13:46 server kernel: sd 0:0:8:0: [sdb] tag#93 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Dec 26 01:13:49 server kernel: mpt3sas_cm0: log_info(0x31120600): originator(PL), code(0x12), sub_code(0x0600)
Ce que cela signifie : Vous avez des timeouts de commandes SCSI et une réinitialisation de lien SATA sur le même chemin. Cela suggère
soit un disque SATA mal comportant sous STP, soit un problème de transport (câble/backplane) provoquant une instabilité de lien.
Décision : Si les réinitialisations se concentrent autour d’un seul disque, remplacez ce disque. Si les réinitialisations affectent plusieurs disques
sur le même « ataX » ou port HBA, inspectez câblage/backplane et firmware HBA.
Task 5: Identify whether a disk is SAS or SATA, and through which host
cr0x@server:~$ sudo lsblk -d -o NAME,MODEL,TRAN,SERIAL,HCTL /dev/sdb
NAME MODEL TRAN SERIAL HCTL
sdb WDC WD140EDFZ sata VGH1ABC1 0:0:8:0
Ce que cela signifie : TRAN=sata vous indique qu’il s’agit d’un disque SATA même s’il est dans un châssis SAS.
HCTL montre l’adresse SCSI. Décision : Attendez-vous à plus de bizarreries liées à STP ; soyez plus conservateur sur la sensibilité aux timeouts et à la qualité du câblage.
Task 6: Inspect SMART for evidence of slow recovery or link trouble (SATA)
cr0x@server:~$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD140EDFZ-11A0VA0
Serial Number: VGH1ABC1
SATA Version is: SATA 3.3, 6.0 Gb/s
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
197 Current_Pending_Sector 0x0012 200 200 0 Old_age Always - 3
198 Offline_Uncorrectable 0x0010 200 200 0 Old_age Offline - 3
199 UDMA_CRC_Error_Count 0x003e 199 199 0 Old_age Always - 24
Ce que cela signifie : Des secteurs en attente/offline uncorrectable suggèrent des problèmes média ; des UDMA CRC errors suggèrent
des problèmes de liaison/câble/backplane. Décision : Les secteurs en attente pendant les scrubs sont un signal d’alarme — planifiez le remplacement.
CRC errors : réinsérez/remplacez le câble/le chemin backplane et surveillez si le compteur continue d’augmenter.
Task 7: Inspect SMART for SAS with richer error logs
cr0x@server:~$ sudo smartctl -a /dev/sde
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Vendor: SEAGATE
Product: ST12000NM000J
Revision: SN03
Logical Unit id: 0x5000c500d3a1b2c3
Transport protocol: SAS (SPL-3)
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 34 C
Elements in grown defect list: 8
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
read: 1200 2 1202 1200 98123.456 0
write: 0 0 0 0 77234.112 0
Ce que cela signifie : Des défauts croissants existent mais les lectures sont encore corrigées sans erreurs non corrigées.
Le SAS vous donne une image plus claire de l’activité de correction. Décision : Suivez le « grown defect list » et les taux d’erreurs corrigées.
S’ils s’accélèrent ou si vous voyez des erreurs non corrigées/timeouts, remplacez de manière proactive.
Task 8: Check HBA driver/firmware and spot known reset storms
cr0x@server:~$ sudo lspci -nn | grep -i -E "sas|lsi|broadcom"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)cr0x@server:~$ sudo modinfo mpt3sas | egrep "version|firmware"
version: 46.100.00.00
firmware: 0x2221 (IR)
Ce que cela signifie : Vous devez savoir ce que vous exécutez. Un HBA en mode IR, par exemple, peut ne pas être ce que vous voulez pour le passthrough ZFS.
Décision : Assurez-vous que le HBA est en mode IT pour ZFS, et maintenez des combinaisons firmware/driver cohérentes sur la flotte.
Si vous voyez des réinitialisations, vérifiez que vous n’êtes pas sur une combinaison problématique.
Task 9: Check link error counters (SAS phy stats)
cr0x@server:~$ for phy in /sys/class/sas_phy/phy-*; do echo "== $phy =="; sudo cat $phy/invalid_dword_count $phy/running_disparity_error_count $phy/loss_of_dword_sync_count $phy/phy_reset_problem_count 2>/dev/null; done | head -n 20
== /sys/class/sas_phy/phy-0:0 ==
0
0
0
0
== /sys/class/sas_phy/phy-0:1 ==
12
5
3
1
Ce que cela signifie : Des compteurs non nuls de disparity/sync/reset sont des problèmes de couche physique : câble, backplane,
port expander, ou connecteur marginal. Décision : Si les compteurs augmentent dans le temps, remplacez les composants du chemin
avant de blâmer ZFS ou le disque.
Task 10: Identify which disks share an expander/backplane path
cr0x@server:~$ sudo lsscsi -t
[0:0:0:0] disk sas:0x5000c500d3a1b2c3 /dev/sde
[0:0:1:0] disk sas:0x5000c500d3a1b2c4 /dev/sdf
[0:0:8:0] disk sata:0x50014ee2b7c81234 /dev/sdb
[0:0:9:0] disk sata:0x50014ee2b7c85678 /dev/sdc
Ce que cela signifie : Vous voyez les périphériques SAS vs SATA, et pouvez souvent déduire quels sont derrière un expander.
Décision : Si plusieurs périphériques sur le même hôte/canal montrent des erreurs ensemble, suspectez un chemin partagé.
Task 11: Observe per-disk latency and queue depth during pain
cr0x@server:~$ iostat -x -d 2 3 /dev/sdb /dev/sdc
Linux 6.6.0 (server) 12/26/2025 _x86_64_ (32 CPU)
Device r/s w/s rkB/s wkB/s await aqu-sz %util
sdb 8.0 1.0 512 64 980.0 31.5 99.9
sdc 210.0 12.0 86000 1200 12.4 2.1 88.0
Ce que cela signifie : sdb a ~1 seconde de latence moyenne et une file énorme. Il ne suit pas,
il se bloque. Décision : Si cela se corrèle avec des timeouts noyau, vous avez un problème de périphérique/chemin sur sdb. Remplacez le disque ou réparez le transport ; ne vous contentez pas de « tuner ZFS » en espérant.
Task 12: Check for ZFS slow I/O messages
cr0x@server:~$ sudo dmesg -T | grep -i "slow io" | tail
[Thu Dec 26 01:13:55 2025] ZFS: vdev IO failure, zio 0x0000000123456789, type 1, offset 231145472, size 131072
[Thu Dec 26 01:13:55 2025] ZFS: vdev slow I/O, zio 0x0000000123456790, 60 seconds
Ce que cela signifie : ZFS vous indique que des E/S prennent des dizaines de secondes. Cela correspond généralement à une récupération du disque
ou à des réinitialisations de transport. Décision : Traitez les « slow I/O » répétés comme un indicateur de pré-faille ; ce n’est pas du bruit de fond normal.
Task 13: Throttle scrub impact (Linux OpenZFS)
cr0x@server:~$ sudo zfs get -H -o property,value autotrim tank
autotrim offcr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
10cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
4
Ce que cela signifie : Vous avez réduit le nombre d’E/S concurrentes de scrub par vdev, diminuant la pression.
Décision : Utilisez cela comme levier temporaire de stabilité pendant la réponse à l’incident. Si la limitation fait disparaître les timeouts, vous avez quand même un composant faible — juste un qui ne casse qu’en contrainte.
Task 14: Temporarily pause and resume a scrub to stop the bleeding
cr0x@server:~$ sudo zpool scrub -p tankcr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
pool: tank
state: DEGRADED
scan: scrub paused since Thu Dec 26 01:20:11 2025
3.80T scanned at 0B/s, 2.41T issued at 0B/s, 12.8T total
Ce que cela signifie : Mettre en pause réduit la charge pour que vous puissiez stabiliser et enquêter sans continuer à piquer le composant défaillant.
Décision : Mettez en pause pendant des tempêtes de timeouts actives ; reprenez après avoir corrigé le disque/chemin suspect ou après avoir appliqué des throttles.
Task 15: Offline a flapping disk to protect the pool (carefully)
cr0x@server:~$ sudo zpool offline tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1cr0x@server:~$ sudo zpool status -v tank | sed -n '1,25p'
pool: tank
state: DEGRADED
status: One or more devices is being resilvered or is offline.
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
ata-WDC_WD140EDFZ-... OFFLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 3
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
ata-WDC_WD140EDFZ-... ONLINE 0 0 0
Ce que cela signifie : Vous avez retiré un périphérique qui clignote du chemin d’E/S. Cela peut arrêter les réinitialisations du bus et protéger les disques restants.
Décision : Ne le faites que si la redondance le permet (sécurité RAIDZ2/mirror). Si vous êtes à un disque de la perte de données, réparez d’abord le chemin et évitez d’offliner à moins que le disque n’empoisonne tout le vdev.
Task 16: Replace the disk and monitor resilver progress
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_VGH9NEW1cr0x@server:~$ sudo zpool status tank | sed -n '1,22p'
pool: tank
state: DEGRADED
scan: resilver in progress since Thu Dec 26 02:01:09 2025
1.22T scanned at 421M/s, 512G issued at 176M/s, 12.8T total
0B repaired, 3.90% done, 5:48:12 to go
Ce que cela signifie : Le resilver est en cours. Surveillez de nouveaux timeouts pendant le resilver ; c’est le moment où les composants marginaux se confient.
Décision : Si le resilver déclenche de nouveaux timeouts sur d’autres disques, vous avez probablement un problème de chemin partagé ou un autre disque faible.
Task 17: Check SATA error handling parameters (Linux SCSI layer)
cr0x@server:~$ cat /sys/block/sdb/device/timeout
30cr0x@server:~$ echo 60 | sudo tee /sys/block/sdb/device/timeout
60
Ce que cela signifie : L’OS attendra plus longtemps avant de déclarer une commande timed out. Cela peut réduire les faux positifs avec des disques lents, mais cela peut aussi masquer de vrais blocages et prolonger les arrêts.
Décision : N’utilisez l’augmentation des timeouts qu’en solution palliative et seulement si vous comprenez le compromis. Si un disque a besoin de 90 secondes pour lire un secteur, vous n’avez pas un problème de timeout — vous avez un problème de disque.
Task 18: Verify ZFS isn’t being sabotaged by write cache surprises
cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
write-caching = 1 (on)
Ce que cela signifie : Le cache d’écriture est activé. C’est normal, mais sur certains disques grand public et certaines enceintes, cache + comportement en cas de coupure de courant peut être risqué.
Décision : Si vous n’avez pas de protection contre les pertes de puissance et que vous tenez aux sémantiques sync, envisagez un SLOG pour les charges sync intensives et des disques entreprise pour un comportement prévisible plutôt que de basculer le cache au hasard.
Erreurs courantes : symptômes → cause racine → correction
1) Symptom: “ZFS keeps faulting different disks during scrub”
- Cause racine : Réinitialisations de chemin partagé (backplane, expander, câble ou HBA) provoquant des timeouts sur plusieurs périphériques, pas plusieurs disques défectueux.
- Correction : Corrélez quels disques clignotent ensemble via les logs noyau et HCTL. Remplacez câble/backplane/expander ; mettez à jour le firmware HBA ; réduisez la complexité du domaine de reset.
2) Symptom: “SMART looks fine but I see command timeouts”
- Cause racine : Les disques peuvent se bloquer en récupération d’erreur sans déclencher les seuils SMART ; les erreurs de transport ne se traduisent pas toujours par des échecs SMART classiques.
- Correction : Traitez les timeouts comme un signal d’échec de première classe. Suivez les compteurs CRC/link et les réinitialisations noyau ; remplacez le disque ou le chemin avant que cela ne devienne un incident de perte de données.
3) Symptom: “Resilver is painfully slow and the pool feels unstable”
- Cause racine : Parallélisme de rebuild agressif saturant les files ; un disque faible se bloque sous charge ; ou un disque SATA effectue de longues retries internes.
- Correction : Limitez temporairement les paramètres scrub/resilver, protégez la latence en production, et remplacez tout disque montrant de longs awaits/timeouts.
4) Symptom: “Checksum errors appear, then disappear after a reboot”
- Cause racine : Liaison intermittente ou corruption mémoire ; le reboot masque temporairement le problème en réinitialisant le chemin.
- Correction : Ne vous réjouissez pas. Lancez des tests mémoire, vérifiez les logs ECC, et inspectez les compteurs SAS phy ou CRC SATA. Remplacez les composants marginaux.
5) Symptom: “Only SATA drives drop; SAS drives don’t”
- Cause racine : Traduction STP + comportement de récupération d’erreur des disques grand public + plus grand rayon d’impact des resets.
- Correction : Utilisez des disques entreprise/NAS avec récupération bornée si disponibles ; préférez le SAS pour les châssis multi-baies denses ; assurez-vous que le backplane et le HBA sont validés pour des charges SATA.
6) Symptom: “After replacing one disk, another starts timing out during resilver”
- Cause racine : Le resilver a créé assez de stress pour révéler le disque suivant le plus faible ou un chemin de transport marginal.
- Correction : Lancez un scrub complet après le resilver, surveillez iostat/latence, et remplacez de manière proactive tout disque avec augmentation des pending sectors ou des slow I/O répétés.
Checklists / plan pas à pas
Step-by-step: when you see timeouts during scrub/resilver
- Geler le rayon d’impact : mettez le scrub en pause si le système est instable et que la production est impactée.
- Capturer des preuves : sauvegardez
zpool status -v,zpool iostat -v, et les logs noyau couvrant la fenêtre d’événement. - Identifier le(s) périphérique(s) suspect(s) : mappez by-id → /dev/sdX et notez les adresses HCTL.
- Distinguer média vs transport : SMART pending/offline uncorrectable suggère média ; compteurs CRC/link suggèrent transport.
- Vérifier la corrélation de chemin partagé : plusieurs disques partagent-ils le même hôte/port/segment de backplane ?
- Appliquer des throttles temporaires : réduisez le parallélisme scrub/resilver pour stabiliser pendant l’intervention.
- Corriger la cause la plus probable : remplacez câble/backplane en premier si les compteurs de lien augmentent ; remplacez le disque s’il se bloque seul ou montre des erreurs média.
- Reprendre scrub/resilver et surveiller : si les erreurs réapparaissent, vous avez manqué le véritable maillon faible.
- Hygiène post-incident : planifiez un scrub complet après le resilver et revoyez les tendances des compteurs d’erreurs chaque semaine pendant un mois.
Decision checklist: when to choose SAS over SATA for ZFS
- Choisissez SAS si vous avez un châssis dense, des expanders, beaucoup de disques par HBA, ou des exigences strictes de disponibilité.
- Choisissez SAS si vous prévoyez des resilvers fréquents (pools volumineux, fort churn) et que vous voulez une récupération d’erreur bornée par défaut.
- Choisissez SATA si le coût/To prime, votre châssis est simple, et que vous êtes prêt à être impitoyable sur les modèles de disques, le câblage et le remplacement proactif.
- Évitez de mélanger des SKU SATA « peu coûteux ce trimestre » dans le même pool. La cohérence vaut mieux que la surprise.
Configuration checklist: make SATA behave less like a hobby
- Utilisez un vrai HBA en mode IT ; évitez les personnalités RAID.
- Privilégiez des backplanes de qualité et des câbles courts et étiquetés ; remplacez tout ce qui incrémente les compteurs CRC.
- Planifiez les scrubs hors-pointe et limitez-les si la latence compte.
- Suivez les timeouts et les réinitialisations, pas seulement le « SMART PASSED ».
- Gardez des disques de rechange à portée ; remplacez au premier signe de slow I/O sous scrub, pas après le troisième incident.
FAQ
1) Is SAS inherently more reliable than SATA?
Pas intrinsèquement. Les écosystèmes SAS sont typiquement conçus pour un comportement d’échec prévisible sous stress multi-disques.
Cette prévisibilité est ce que les opérateurs interprètent comme de la fiabilité.
2) Why do SATA drives “drop out” during ZFS scrub?
Souvent parce que le disque se met en pause pour une récupération d’erreur interne, l’OS timeoute la commande, et le contrôleur réinitialise le lien. Avec STP derrière un HBA SAS, cette réinitialisation peut être bruyante.
3) If ZFS has checksums, why do timeouts matter?
Les checksums détectent la corruption. Ils ne garantissent pas que les E/S se termineront dans les délais. ZFS a toujours besoin que le périphérique réponde dans la fenêtre de timeout de l’OS pour garder le pool en ligne et cohérent.
4) Should I increase Linux disk timeouts to stop flapping?
Parfois en tant que mitigation temporaire. Mais des timeouts plus longs augmentent la durée des blocages et peuvent masquer un média défaillant.
Si un disque nécessite des timeouts beaucoup plus longs, la réponse la plus sûre est le remplacement ou l’utilisation de disques avec un comportement de récupération borné.
5) Do SAS expanders cause timeouts?
Ils peuvent si le firmware est bogué, la topologie est surchargée, ou le câblage est marginal. Mais un bon expander dans une topologie saine n’est pas un problème. Un câble défectueux faisant croire à un problème d’expander est extrêmement courant.
6) Are checksum errors always a disk problem?
Non. Elles peuvent provenir du disque, du câble, du HBA, du backplane ou d’une corruption mémoire. C’est pourquoi la corrélation des logs noyau, des compteurs de lien et du SMART est obligatoire.
7) Why does SAS “fail fast” feel better for ZFS?
Parce que la redondance ZFS fonctionne mieux quand un périphérique signale une erreur rapidement afin que ZFS puisse reconstruire et guérir. De longues pauses silencieuses provoquent des timeouts, des réinitialisations et des dommages collatéraux multi-périphériques.
8) Is mixing SAS and SATA in the same pool a bad idea?
Ce n’est pas interdit, mais c’est gênant en exploitation. Les comportements de timeout et la télémétrie différents compliquent l’interprétation des incidents. Si vous devez mélanger, isolez par classe de vdev ou par usage de pool et documentez les attentes.
9) What’s the single biggest indicator that I have a cabling/backplane issue?
Des erreurs affectant plusieurs disques partageant un chemin physique, plus des compteurs CRC/link en hausse. Les défaillances média sont habituellement localisées ; les défaillances de transport aiment la compagnie.
10) What should I optimize for: scrub speed or stability?
La stabilité. Un scrub est une procédure de sécurité. Si vous avez besoin qu’il se termine plus vite, augmentez la capacité ou planifiez mieux.
Ne transformez pas votre vérification de redondance en un événement de déni de service.
Conclusion : prochaines étapes pour éviter le réveil nocturne
Le SAS paraît plus stable sous le stress ZFS parce que l’ensemble de la pile — disques, protocole et contrôleurs — a tendance à renvoyer des erreurs rapidement, à isoler les réinitialisations et à fournir une télémétrie plus claire.
Le SATA peut très bien fonctionner, parfois brillamment, mais il est beaucoup moins tolérant quand quelque chose est marginal et a beaucoup plus de chances de transformer un disque faible en incident affectant tout le bus.
Étapes pratiques :
- Classez vos erreurs (checksum vs timeout vs transport) et arrêtez de les traiter comme interchangeables.
- Corrélez les défaillances aux chemins partagés en utilisant HCTL et les compteurs de lien ; remplacez câbles/backplanes de manière proactive.
- Remplacez les disques qui se bloquent sous scrub même si SMART dit « PASSED ». Votre pool a besoin d’E/S en temps voulu, pas d’optimisme.
- Limitez scrub/resilver pour protéger la latence production, puis corrigez la faiblesse sous-jacente au lieu de vivre sur des throttles.
- Si la disponibilité importe, achetez SAS pour les systèmes multi-baies denses. Vous payez pour un comportement de défaillance borné et un rayon de reset plus petit.
Une idée paraphrasée à garder sur un post-it, attribuée avec précaution : paraphrased idea
— John Allspaw : la fiabilité vient de la construction de systèmes qui attendent des pannes et récupèrent de façon prévisible.