Alertes SMART dans Proxmox : quels attributs prédisent réellement une panne

Comment SMART fonctionne réellement (et comment Proxmox l’utilise)

SMART est une télémétrie spécifique au fournisseur enveloppée dans un conteneur standardisé. Le firmware du disque décide quoi compter, quand incrémenter et comment cartographier les valeurs « normalisées ». Vous ne lisez pas la physique objective. Vous lisez ce que le disque accepte d’admettre.

SMART fournit trois types de signaux qui importent en exploitation :

• Drapeaux de défaillance (état global SMART « PASSED/FAILED », NVMe « critical_warning »). Ce sont des instruments brutaux. Certains disques échouent sans les déclencher. D’autres les déclenchent tardivement.
• Compteurs de dégradation média (secteurs réalloués, secteurs en attente, erreurs non corrigibles, erreurs média NVMe). Ceux-ci corrèlent avec la détérioration de la surface ou de la NAND et prédisent l’avenir mieux que la plupart.
• Compteurs de transport et d’environnement (erreurs CRC, historique de température, arrêts non sûrs). Ils concernent souvent les câbles, backplanes, l’alimentation et le comportement.

Proxmox récupère généralement les données SMART via smartmontools (smartctl/smartd) pour les périphériques SATA/SAS et via les journaux NVMe pour les NVMe. Dans l’interface, vous verrez souvent un « État » résumé plus une poignée d’attributs. Les résumés sont pour les humains. Les incidents sont pour les données brutes.

Si vous ne retenez qu’une chose : SMART est un outil de tendance, pas un outil de snapshot unique. Un seul nombre non nul peut être bénin s’il ne change jamais. Un petit nombre qui monte est une sirène.

Une citation à garder près de votre carnet d’astreinte : L’espoir n’est pas une stratégie. — Général Gordon R. Sullivan. Ce n’est pas spécifique au stockage, mais c’est douloureusement applicable aux décisions « probablement OK » pour un disque.

Blague n°1 : SMART, c’est comme le rapport de blessures d’un tout-petit : bruyant pour les mauvaises choses, discret pour les choses effrayantes.

Faits intéressants et courte histoire qui changent la lecture de SMART

• SMART prédate les SSD modernes. Il a été popularisé dans les années 1990 pour les disques rotatifs, et beaucoup d’attributs portent encore des hypothèses de l’ère HDD.
• Les valeurs « normalisées » sont de la fiction constructeur. Les attributs « VALUE/WORST/THRESH » sont mises à l’échelle et définies par le fournisseur ; le compteur brut est souvent plus actionnable.
• SMART initial était surtout sur la « prédiction de panne ». La promesse originale était un avertissement avant panne. En pratique, beaucoup de pannes sont brusques (électronique, firmware, événements d’alimentation).
• Les études d’envergure comme Backblaze ont popularisé quelques attributs. Les données de flotte ont rendu célèbres les secteurs réalloués et en attente pour les HDD, mais la relation n’est pas identique entre tous les modèles.
• SMART pour SSD est moins standardisé qu’on le croit. Les indicateurs d’usure (pourcentage utilisé, wear leveling) sont utiles, mais les journaux spécifiques au fournisseur restent importants.
• Les tests SMART sont « offline » mais pas inoffensifs. Les tests longs peuvent stresser des disques marginaux et ralentir les performances ; c’est une fonctionnalité quand vous validez une décision de remplacement.
• Les erreurs de transport n’ont souvent rien à voir avec le disque. Un compteur CRC qui monte hurle « câble/backplane » plutôt que « défaillance média ».
• ZFS et Ceph font déjà leur propre recherche de la vérité. Les erreurs de checksum ZFS et les erreurs Ceph « bluestore » peuvent révéler la corruption même quand SMART est calme.
• Le firmware du disque peut remapper des secteurs en silence. La réallocation est parfois proactive ; le disque peut remplacer des secteurs faibles avant que vous ne voyiez une erreur non corrigible.

Les attributs SMART qui prédisent vraiment une panne

« Prédire » porte un poids ici. Aucun attribut n’est une prophétie. Mais certains corrèlent systématiquement avec des disques qui empirent rapidement. Ce sont ceux qui méritent un ticket d’incident, pas un haussement d’épaules.

Pour les HDD SATA : les trois grands qui comptent le plus

1) Reallocated Sector Count (ID 5)

C’est le métrique canonique de « la média se dégrade ». Un secteur réalloué est un secteur que le disque n’a pas pu lire/écrire de manière fiable et qu’il a remplacé par un secteur de secours.

Comment le traiter en production :

• Zéro est la baseline. Non nul signifie que le disque a déjà consommé des secteurs de rechange.
• Un non nul stable peut être acceptable s’il n’augmente pas sur des semaines et que les scrubs n’affichent pas d’erreurs de lecture.
• Des réallocations qui augmentent déclenchent le remplacement. Pas à cause du nombre en soi, mais parce que le disque vous dit qu’il continue de perdre la bataille.

2) Current Pending Sector (ID 197)

Les secteurs en attente sont pires que les réallocations à court terme. Ce sont des secteurs que le disque a du mal à lire et qu’il n’a pas encore remappés — souvent parce qu’il veut une écriture réussie pour confirmer s’il peut remapper.

Sens opérationnel : vous avez des données que le disque ne peut pas lire de manière fiable. C’est comme on obtient des timeouts, des lectures lentes et éventuellement des erreurs non corrigibles.

Règle décisionnelle : Pending > 0 sur un membre ZFS/RAID mérite un suivi immédiat : lancez un test long et vérifiez les erreurs ZFS/Ceph. Si les pending persistent ou augmentent, planifiez le remplacement.

3) Uncorrectable Sector Count / Offline Uncorrectable (ID 198) et Reported Uncorrectable Errors (ID 187)

Si le disque admet qu’il n’a pas pu corriger des lectures pendant un scan offline (198) ou pendant les opérations normales (187), considérez-le comme « risque d’intégrité des données présent ».

En RAIDZ/mirrors vous pourriez survivre. Sur un système mono-disque vous pourriez ne pas. Dans les deux cas, le disque n’est plus « ennuyeux », et l’état ennuyeux est l’état souhaité.

Pour les SSD SATA : les attributs qui importent

1) Media Wearout Indicator / Percentage Used / Wear Leveling Count

Différents fournisseurs appellent cela différemment. Vous voulez un indicateur direct de l’usure de la NAND. Quand cela approche la fin de vie, vous attendez :

• des écritures plus lentes
• une surcharge de correction d’erreurs
• le mode lecture seule sur certains modèles

Règle décisionnelle : Quand l’usure indique que vous êtes dans le dernier quart de la vie rated, planifiez le remplacement à votre rythme, pas au rythme du disque.

2) Reallocated sectors / reallocation events (varie)

Les SSD remappent différemment des HDD, mais une métrique de type réallocation qui augmente corrèle souvent avec une NAND ou un contrôleur défaillant. Si elle monte, traitez-la comme les réallocations HDD : suivez la tendance et planifiez un remplacement.

3) Uncorrectable errors

Les non-correctibles sur SSD sont un mauvais signe. Ils sont moins fréquents que sur des HDD en fin de vie, et quand ils apparaissent ils signifient souvent un problème contrôleur/NAND qui ne s’améliore pas.

Pour NVMe : quelques champs qui importent plus que douze attributs SATA

1) Critical Warning

C’est un bitmask. Tout non-zéro mérite de l’attention. Il peut indiquer faible capacité de spare, problèmes de température ou mode lecture seule média.

2) Percentage Used

C’est exactement ce que cela signifie : usure relative à la durée de vie nominale du fabricant. Pas parfait, mais bien meilleur que deviner à partir des heures de fonctionnement.

3) Media and Data Integrity Errors

Souvent exposé comme « Media and Data Integrity Errors » dans SMART NVMe. Non nul et en augmentation signifie que le périphérique échoue à fournir des données correctes sans récupération.

4) Error Information Log Entries

C’est le compteur « quelque chose se passe mal sans arrêt ». Il peut s’incrémenter pour des erreurs récupérables aussi, donc corrélez avec des pics de latence, des erreurs I/O dans les logs et des erreurs de checksum ZFS.

La tendance bat le seuil

La plupart des valeurs « THRESH » SMART sont réglées si bas qu’à l’instant où elles déclenchent, vous avez déjà eu une mauvaise semaine. Vos seuils opérationnels doivent être plus conservateurs :

• Toute augmentation des pending ou non-correctibles mérite une enquête immédiate.
• Réallocations qui augmentent mois après mois déclenchent un remplacement planifié.
• Erreurs média NVMe en augmentation déclenchent une planification de remplacement ; une augmentation rapide déclenche un remplacement urgent.
• Erreurs de transport en augmentation déclenchent des travaux sur câblage/backplane/alimentation avant d’accuser le disque.

Les attributs bruyants qui vous font perdre du temps

Certaines valeurs SMART sont notoirement trompeuses parce que les fournisseurs codent plusieurs sous-compteurs dans une valeur brute, ou parce que l’attribut dépend fortement de la charge. Les tableaux de bord les aiment car elles bougent. Les ingénieurs les détestent car elles ne répondent pas à la question « ce disque va-t-il tomber ? »

Raw Read Error Rate (ID 1) et Seek Error Rate (ID 7)

Sur beaucoup de modèles Seagate ces nombres bruts paraissent terrifiants et continuent d’augmenter même sur des disques sains. Ce n’est pas votre incident. Suivez la valeur normalisée si nécessaire, mais ne remplacez pas un disque uniquement sur la base d’un taux brut effrayant.

Hardware ECC Recovered (ID 195)

Des nombres élevés de récupérations ECC signifient souvent « la correction d’erreurs fait son travail ». Ce n’est pas automatiquement mauvais. Cela devient intéressant seulement s’il coïncide avec des non-correctibles, des timeouts ou des erreurs de checksum ZFS.

Spin Retry Count (ID 10) et Start/Stop Count (ID 4)

Ceux-ci dépendent de la charge et de la gestion d’alimentation. Les comptes start/stop sont particulièrement abusés par des head parking agressifs. Des valeurs élevées ne prédisent pas nécessairement une panne imminente ; elles prédisent que vous avez configuré la gestion d’alimentation comme un portable.

Power-On Hours (ID 9)

L’âge compte, mais ce n’est pas déterministe. J’ai remplacé des disques neufs arrivés déjà endommagés et maintenu des disques entreprise de 7 ans en vie en les traitant doucement et en regardant les bons compteurs.

Temperature (ID 194/190)

La température est un facteur de risque, pas un prédicteur de panne en soi. Des températures élevées persistantes accélèrent l’usure et peuvent déclencher du throttling ou des taux d’erreur, mais un pic ponctuel pendant une reconstruction n’est pas une sentence de mort.

Où Proxmox affiche SMART et ce que cela vous dit réellement

Dans Proxmox VE, vous voyez typiquement SMART sous node → Disks → SMART. Il peut aussi afficher la santé dans la vue stockage selon votre configuration. L’interface est pratique pour un coup d’œil, mais ce n’est pas là que vous faites l’analyse de cause racine.

Utilisez l’interface pour repérer « quelque chose a changé ». Puis passez au shell et récupérez :

• les attributs SMART complets (pas seulement ceux que l’UI rend)
• le journal d’erreurs SMART
• l’historique des auto-tests
• les logs noyau montrant timeouts/réinitialisations
• l’état des scrubs et checksums ZFS/Ceph

Aussi : Proxmox tourne souvent sur des hôtes avec des HBA, backplanes et parfois des contrôleurs RAID. Le passthrough SMART peut être incomplet. Si SMART est manquant ou retourne toujours « UNKNOWN », ce n’est pas le disque qui est mystérieux ; c’est votre chemin de stockage qui est opaque.

Tâches pratiques : commandes, ce que signifie la sortie, et la décision à prendre

Voici les tâches que j’exécute réellement quand des alertes SMART apparaissent sur Proxmox. Chacune inclut le « et alors » décisionnel, car collecter des nombres sans décisions, c’est juste accumuler des logs inutilement.

Task 1: Confirm the device path and model (avoid blaming the wrong disk)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME   SIZE MODEL               SERIAL            TYPE MOUNTPOINT
sda   3.6T  ST4000NM0035-1V4    ZC1ABC12          disk
sdb   3.6T  ST4000NM0035-1V4    ZC1ABD34          disk
nvme0n1 1.8T INTEL SSDPE2KX020T8 PHBT1234001      disk

Signification : Faites correspondre les noms Linux aux disques physiques (modèle + serial). Les noms de périphérique dans l’UI Proxmox peuvent changer après un reboot ou des modifications HBA.

Décision : Si vous ne pouvez pas rattacher l’alerte à un numéro de série, arrêtez-vous. Construisez ce mapping d’abord, sinon vous retirerez le mauvais disque et apprendrez l’humilité à la dure.

Task 2: Pull full SMART health summary for a SATA/SAS disk

cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST4000NM0035-1V4107
Serial Number:    ZC1ABC12
LU WWN Device Id: 5 000c50 0a1b2c3d4
Firmware Version: SN04
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== 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   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Signification : « PASSED » n’annule pas les pending/uncorrectables. Ici on a des réallocations, des secteurs en attente et des offline uncorrectables : trouble média classique.

Décision : Si 197 ou 198 est non nul, escaladez. Lancez un test long, vérifiez l’état ZFS/Ceph et planifiez le remplacement si les chiffres persistent ou augmentent.

Task 3: Pull NVMe health and the critical warning bit

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPE2KX020T8
Serial Number:                      PHBT1234001
Firmware Version:                   VDV10131
PCI Vendor/Subsystem ID:            0x8086
IEEE OUI Identifier:                0x5cd2e4
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.4
Number of Namespaces:               1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        44 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    63%
Media and Data Integrity Errors:    0
Error Information Log Entries:      18

Signification : Percentage Used commence à être élevé (63%), mais ce n’est pas la fin de vie en soi. « Error Information Log Entries » est non nul ; corrélez avec les logs et les symptômes de performance.

Décision : Si Critical Warning est non nul ou si Media and Data Integrity Errors augmente, planifiez le remplacement. Si seuls les error log entries augmentent sans erreurs d’intégrité, enquêtez d’abord sur le firmware/driver/timeouts.

Task 4: Check SMART error log (the drive’s confession list)

cr0x@server:~$ sudo smartctl -l error /dev/sda
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  SC = Sector Count Register [HEX]
  SN = Sector Number Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 4231 hours
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  0000001a2b3c  ...
  Commands leading to the command that caused the error were:
  READ FPDMA QUEUED

Signification : Des erreurs lors de lectures sont cohérentes avec pending/uncorrectables. Si les erreurs sont anciennes et n’augmentent pas, moins urgent.

Décision : Si le compteur d’erreurs s’incrémente durant votre fenêtre d’incident, considérez-le comme une instabilité en cours. Préparez le remplacement et la résilience/reconstruction.

Task 5: Check SMART self-test history

cr0x@server:~$ sudo smartctl -l selftest /dev/sda
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       10%      4232         0x0000001a2b3c
# 2  Short offline       Completed without error       00%      4200         -

Signification : Le test long a rencontré une erreur de lecture à un LBA précis. Ce n’est pas « surveiller ». C’est « planifiez le remplacement ».

Décision : Remplacez le disque. Si c’est dans un mirror/RAIDZ/OSD Ceph, démarrez la récupération contrôlée maintenant, pas après qu’il ait empiré.

Task 6: Run a short SMART test (quick triage)

cr0x@server:~$ sudo smartctl -t short /dev/sda
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 26 02:16:04 2025
Use smartctl -l selftest /dev/sda to read test results.

Signification : Les tests courts détectent vite les problèmes évidents. Ils ne scannent pas complètement la surface.

Décision : Si le test court échoue, fin du débat. Remplacez. S’il passe mais que vous avez des pending/uncorrectables, lancez un test étendu ensuite.

Task 7: Run an extended SMART test (surface scan, the “prove it” test)

cr0x@server:~$ sudo smartctl -t long /dev/sda
Please wait 411 minutes for test to complete.
Test will complete after Tue Dec 26 09:06:11 2025
Use smartctl -l selftest /dev/sda to read test results.

Signification : Les tests étendus scannent la surface et ont tendance à vider les secteurs marginaux.

Décision : Si le test signale des échecs de lecture, remplacez. S’il se termine mais que les pending restent, ne déclarez pas victoire avant d’avoir vérifié que les pending ont disparu et qu’aucune nouvelle erreur n’apparaît en charge.

Task 8: Identify whether “CRC errors” are cabling/backplane, not disk

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|CRC|199'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

Signification : Les erreurs CRC sont presque toujours de la corruption au niveau liaison entre le disque et le contrôleur : câble, connecteur, expander, backplane, vibration ou bruit d’alimentation.

Décision : Si ce compteur augmente, reseat/remplacez le câble, changez de baie, vérifiez le backplane et inspectez les logs noyau pour des resets de lien. Ne RMA pas le disque en premier à moins que d’autres attributs média ne soient aussi mauvais.

Task 9: Correlate with kernel logs for timeouts and resets

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i 'ata[0-9]|reset|timeout|I/O error|nvme'
Dec 26 01:41:08 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 01:41:08 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 26 01:41:09 server kernel: ata3: hard resetting link
Dec 26 01:41:14 server kernel: blk_update_request: I/O error, dev sda, sector 43905102 op 0x0:(READ)

Signification : Resets de lien plus erreurs I/O : peut être média ou transport. Combinez cela avec SMART 199 et 5/197/198.

Décision : Si 5/197/198 sont propres mais que des resets de lien arrivent, traitez d’abord câblage/HBA/backplane. Si 197/198 sont non nuls et que vous voyez des erreurs I/O, traitez comme une panne de disque en cours.

Task 10: ZFS health: see what the filesystem thinks (it’s usually right)

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear' or 'zpool replace'.
  scan: scrub repaired 0B in 00:18:11 with 0 errors on Tue Dec 24 03:12:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-ST4000NM0035_ZC1ABC12  FAULTED     12    0    34  too many errors
            ata-ST4000NM0035_ZC1ABD34  ONLINE      0    0     0

errors: Permanent errors have been detected in the following files:
/rpool/vm-100-disk-0

Signification : ZFS voit de vraies erreurs de lecture/checksum et a marqué le périphérique comme faulted. C’est au-delà d’une alerte SMART ; c’est un incident d’intégrité.

Décision : Remplacez immédiatement le disque. Puis traitez les erreurs permanentes : restaurez depuis la réplication/sauvegarde pour les blocs ou disques VM affectés.

Task 11: ZFS scrub on demand (when you need truth, not comfort)

cr0x@server:~$ sudo zpool scrub rpool
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Tue Dec 26 02:22:10 2025
        215G scanned at 1.20G/s, 48.1G issued at 273M/s, 2.10T total
        0B repaired, 2.31% done, 02:41:18 to go
config:

        NAME                       STATE     READ WRITE CKSUM
        rpool                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABC12  ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABD34  ONLINE       0     0     0

Signification : Un scrub lit tout et vérifie les checksums. Si SMART chuchote mais que ZFS est propre, vous pouvez avoir des indicateurs précoces sans corruption visible pour l’utilisateur.

Décision : Si le scrub signale des erreurs, agissez immédiatement. Si le scrub est propre mais que SMART montre des pending/uncorrectables, planifiez quand même le remplacement — le scrub peut manquer des secteurs non référencés actuellement.

Task 12: Ceph quick health check (if your Proxmox cluster uses it)

cr0x@server:~$ sudo ceph -s
  cluster:
    id:     8f3c2d3e-1b2a-4c5d-9e10-1a2b3c4d5e6f
    health: HEALTH_WARN
            1 osds down
            2 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum a,b,c (age 4h)
    mgr: a(active, since 2d)
    osd: 12 osds: 11 up (since 3m), 12 in (since 7d)

  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.3 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     254 active+clean, 2 active+degraded

Signification : Ceph vous dit qu’un OSD est hors service et que les opérations ralentissent. SMART peut être en cause, mais la santé Ceph est le signal prioritaire.

Décision : Identifiez l’hôte et le disque OSD down, vérifiez SMART/NVMe logs et remplacez/restaurez l’OSD. Ne regardez pas SMART pendant que Ceph saigne.

Task 13: Map a Ceph OSD to a physical disk (stop guessing)

cr0x@server:~$ sudo ceph-volume lvm list
====== osd.4 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABC12
  [block.db]    /dev/nvme0n1p2
  devices       /dev/sda

====== osd.5 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABD34
  [block.db]    /dev/nvme0n1p3
  devices       /dev/sdb

Signification : Vous pouvez maintenant relier « osd.4 » à un serial et une baie spécifiques.

Décision : Remplacez le bon disque, pas son voisin innocent.

Task 14: Look for SATA/NVMe PCIe errors (a “disk problem” that’s really a platform problem)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i 'pcie|aer|nvme.*reset|controller is down'
Dec 25 18:12:44 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
Dec 25 18:12:44 server kernel: nvme nvme0: controller reset
Dec 25 18:12:46 server kernel: nvme nvme0: I/O 37 QID 5 timeout, aborting

Signification : Erreurs PCIe AER corrigées et resets de contrôleur NVMe sont souvent liées à la gestion d’alimentation, bugs firmware, risers ou slots marginaux — pas à la NAND qui s’use.

Décision : Avant de RMA l’NVMe, vérifiez BIOS/firmware, désactivez un ASPM PCIe agressif si besoin, reseat et validez les températures. Remplacez le disque si des erreurs média apparaissent ou si les resets persistent après corrections de plateforme.

Task 15: Trend SMART attributes over time (because “is it getting worse?” is the real question)

cr0x@server:~$ sudo smartctl -A /dev/sda | awk 'NR==1 || $1 ~ /5|187|197|198|199/ {print}'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Signification : C’est votre ensemble « top offenders » pour les HDD SATA. Capturez-le quotidiennement ou hebdomadairement.

Décision : Toute tendance à la hausse sur 197/198/187 est une planification de remplacement. 199 qui augmente est un plan câblage/backplane.

Task 16: Validate drive identity by-id (stable naming for automation and replacement)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ZC1ABC12|nvme-INTEL'
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-ST4000NM0035-1V4107_ZC1ABC12 -> ../../sda
lrwxrwxrwx 1 root root 13 Dec 26 01:10 nvme-INTEL_SSDPE2KX020T8_PHBT1234001 -> ../../nvme0n1

Signification : Utilisez ces identifiants stables dans les chemins vdev ZFS by-id et dans vos runbooks.

Décision : Si votre pool utilise des noms /dev/sdX, planifiez une migration vers les noms by-id avant d’avoir un incident de remplacement.

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

Ceci est la routine « vous avez cinq minutes avant la réunion et 30 secondes avant que le pager n’escalade ». L’objectif n’est pas la vérité parfaite ; c’est un tri rapide : média vs transport vs plateforme vs filesystem.

Premier : déterminer s’il s’agit d’un incident d’intégrité

• ZFS : zpool status -v. Si vous voyez des erreurs CKSUM, des périphériques faulted ou des erreurs permanentes, traitez-le comme un risque d’intégrité des données maintenant.
• Ceph : ceph -s. Si des OSD sont down, ops lentes, PGs dégradés : traitez comme une instabilité de service stockage maintenant.
• Logs noyau : cherchez des erreurs I/O et des resets dans la dernière heure.

Deuxième : séparer la dégradation média du bruit de transport

• Récupérez SMART/NVMe health (smartctl -a).
• Indicateurs média : pending (197), uncorrectables (198/187), reallocated (5), erreurs média NVMe.
• Indicateurs transport : CRC (199), resets de lien, resets phy SAS, AER PCIe, resets contrôleur NVMe sans erreurs média.

Troisième : forcer la question avec un test contrôlé

• Lancez un test SMART court, puis long si nécessaire.
• Lancez un scrub ZFS ou un deep-scrub Ceph si le cluster peut le supporter.
• Surveillez les compteurs après le test. Si les pending se nettoient et qu’aucune nouvelle erreur n’apparaît, vous avez peut-être échappé belle. Si les compteurs montent, remplacez.

Blague n°2 : Si votre « diagnostic rapide » finit par « on reboot et on voit », félicitations — vous pratiquez l’astrologie du stockage.

Trois mini-récits d’entreprise (comment les équipes se trompent et font bien)

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

Une entreprise de taille moyenne exécutait un cluster Proxmox avec des mirrors ZFS. L’astreinte a vu un SMART « PASSED » et un avertissement Proxmox au sujet de quelques secteurs réalloués. Ils ont supposé que c’était OK parce que le pool était toujours ONLINE et les VMs fonctionnaient.

Le détail subtil : le disque avait aussi un petit nombre non nul de Current_Pending_Sector. Cela n’était pas mis en avant dans la vue du tableau de bord. Personne ne l’a suivi. Personne n’a lancé un test long. La vie a continué.

Deux semaines plus tard, un scrub ZFS routinier a commencé. Il a touché un des secteurs en attente pendant une lecture, le disque a timeouté, et le HBA a reset le lien. ZFS a continué d’essayer. La latence a explosé. L’I/O des VMs s’est bloquée. Le cluster n’a pas « perdu de données », mais il a perdu quelque chose de plus précieux dans l’instant : du temps.

Ils ont remplacé le disque après qu’il soit finalement tombé. La résilience a pris plus de temps que prévu parce que le membre miroir survivant faisait désormais le travail sous charge de production. Le postmortem a été franc : l’erreur n’était pas d’ignorer les réallocations ; c’était de traiter les secteurs en attente comme « juste un autre chiffre SMART ».

L’action corrective était ennuyeuse : des snapshots SMART quotidiens des 5/197/198 et un ticket automatique si 197 est non nul ou augmente. Ils n’ont pas arrêté les pannes. Ils ont arrêté les surprises.

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

Une autre équipe voulait moins d’alertes. Leur UI Proxmox affichait des alertes fréquentes de « température » et « UDMA CRC error count » sur quelques nœuds. Les gens se sont habitués et ignoraient les notifications, et naturellement, manquaient les vraies.

Ils ont donc « optimisé » l’alerte : ils ont relevé les seuils et supprimé les alertes CRC parce que « c’est toujours le backplane ». Ils ont aussi supprimé les alertes température car « ces disques chauffent toujours pendant les rebuilds ». Le tableau de bord est devenu plus calme. Tout le monde se sentait mieux.

Des mois plus tard, ils ont eu des pauses VM intermittentes sur un hôte. Rien d’évident dans SMART. Pas de réallocations, pas de pending. Mais les logs noyau montraient des rafales de resets de lien et des incréments CRC pendant les pics de charge. Il s’est avéré qu’un port d’expander SAS était marginal. Les erreurs n’étaient pas constantes ; elles survenaient en tempêtes.

Parce que les alertes CRC étaient supprimées, le problème matériel a traîné. L’expander a continué de se dégrader et a commencé à provoquer des timeouts multi-disques pendant les scrubs. C’est là que ZFS a commencé à montrer des erreurs de checksum. Le système n’a pas échoué à cause d’un seul disque. Il a échoué parce que l’alerte « bruyante » était en réalité leur système d’alerte précoce pour un composant partagé.

La correction n’a pas été « remettre les alertes et souffrir ». Elle a été meilleure : alerter sur le taux de CRC (changement dans le temps), pas sur la valeur brute, et corréler avec un port/baie précis via l’inventaire. Ils ont remplacé l’expander, pas une pile de disques innocents.

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

Une organisation financière utilisait Proxmox avec Ceph. Leur politique était banale : chaque disque a une étiquette avec serial, baie et ID OSD ; chaque semaine ils capturent des résumés SMART/NVMe dans une petite time-series ; chaque mois ils lancent des tests longs planifiés et étalés par nœud.

Un après-midi, Ceph est passé en HEALTH_WARN à cause de quelques slow ops. Rien n’était down. L’astreinte a consulté le dashboard de tendance et a vu qu’un NVMe avait vu ses « Media and Data Integrity Errors » passer de 0 à 1 dans la journée. Juste un. Pas excitant. Mais c’était nouveau.

Ils ont drainé l’hôte, marqué l’OSD out et remplacé le NVMe en heures ouvrées. Les diagnostics du fournisseur ont confirmé plus tard une défaillance média précoce. S’ils avaient attendu que le « Critical Warning » se déclenche, ils auraient subi la panne pendant une fenêtre de maintenance non liée où le cluster était déjà stressé.

La pratique qui les a sauvés n’était pas un outil intelligent. C’était l’habitude de traiter les nouvelles erreurs d’intégrité comme actionnables, même petites, et de faire les remplacements selon leur calendrier.

Erreurs courantes : symptôme → cause racine → correction

1) « SMART PASSED mais Proxmox affiche des avertissements »

Symptôme : L’état global SMART est PASSED ; Proxmox signale quand même un problème de disque.

Cause racine : L’état global est un seuil grossier constructeur ; des compteurs signifiants (pending/uncorrectable) peuvent être non nuls alors que l’état global reste PASSED.

Correction : Ignorez le confort du « PASSED ». Examinez les 5/187/197/198 bruts (SATA) ou les erreurs média/critical warning NVMe. Suivez leur tendance.

2) « UDMA CRC Error Count n’arrête pas d’augmenter ; on a remplacé le disque, le problème persiste »

Symptôme : L’attribut SMART 199 s’incrémente ; des erreurs I/O apparaissent ; remplacer le disque ne résout pas.

Cause racine : Problème de transport : câble SATA, connecteur backplane, expander, port HBA ou instabilité d’alimentation.

Correction : Reseat/remplacez les câbles, changez de baie, inspectez le backplane, mettez à jour le firmware HBA, vérifiez l’alimentation. Remplacez le composant partagé si les erreurs suivent la baie/port, pas le disque.

3) « Erreurs de checksum ZFS mais SMART semble propre »

Symptôme : ZFS rapporte des erreurs CKSUM ; SMART ne montre pas de réallocations/pending.

Cause racine : Corruption de données en transit (câblage/HBA), RAM instable (moins fréquent mais catastrophique) ou bugs firmware/driver. SMART mesure le disque, pas tout le chemin.

Correction : Vérifiez les logs noyau pour resets, CRC, erreurs PCIe. Validez la santé de la RAM ECC (edac). Changez HBA/câbles. Scrubez à nouveau. Ne blâmez pas SMART d’être l’outil inadapté.

4) « Des secteurs en attente sont apparus après un événement d’alimentation »

Symptôme : 197 > 0 après un arrêt brutal ou une coupure de courant.

Cause racine : Écritures incomplètes ou secteurs marginaux exposés par un arrêt soudain ; parfois cela se nettoie après réécriture des secteurs affectés.

Correction : Lancez un test SMART long, puis vérifiez si les pending se nettoient. Si les pending persistent ou des uncorrectables apparaissent, remplacez. Corrigez aussi l’alimentation : onduleur, PSU redondants, arrêts propres.

5) « NVMe réinitialise sous charge ; SMART semble OK »

Symptôme : Resets de contrôleur NVMe et timeouts I/O ; pas d’erreurs média.

Cause racine : Problèmes de plateforme/PCIe : thermiques, firmware, ASPM, risers, slot marginal, alimentation.

Correction : Vérifiez AER logs, thermiques, mises à jour firmware. Envisagez de désactiver une gestion d’énergie agressive. Si les resets persistent, déplacez le périphérique vers un autre slot ou remplacez le composant de plateforme.

6) « Le test long SMART ralentit les VMs, donc on ne le lance jamais »

Symptôme : Vous évitez les tests longs car ils impactent la perf.

Cause racine : Pas de fenêtres de maintenance ; peur de l’impact ; absence d’ordonnancement étalé.

Correction : Étalez les tests par nœud et par disque pendant les périodes de faible charge. Si vous ne supportez pas un SMART long test, vous ne supporterez pas non plus une résilience pendant les heures de pointe.

7) « On alerte sur chaque valeur brute SMART non nulle »

Symptôme : Alertes constantes ; tout le monde les ignore.

Cause racine : Alerte sur des attributs bruyants sans logique de taux/tendance.

Correction : Alertez sur les changements des attributs à fort signal (pending, uncorrectable, reallocations, erreurs média NVMe) et sur le taux de changement pour CRC/température, pas sur les valeurs absolues.

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

Checklist A: When Proxmox throws a SMART warning

1. Identifiez le disque par numéro de série (lsblk, /dev/disk/by-id).
2. Récupérez les données SMART/NVMe complètes (smartctl -a).
3. Extraites les attributs à fort signal :
   • SATA : 5, 187, 197, 198, 199
   • NVMe : Critical Warning, Percentage Used, Media/Data Integrity Errors
4. Vérifiez le journal d’erreurs et l’historique des auto-tests (smartctl -l error, -l selftest).
5. Corrélez avec les logs noyau pour la même fenêtre temporelle (journalctl -k).
6. Vérifiez la santé ZFS/Ceph (zpool status -v ou ceph -s).
7. Prenez une décision :
   • Compteurs média en hausse → remplacer le disque (planifié ou urgent selon le taux).
   • CRC/resets sans compteurs média → corriger transport/plateforme d’abord.
   • Erreurs permanentes ZFS → traiter comme incident d’intégrité et récupérer les blocs/disques VM.

Checklist B: Replacement decision rules I actually use

• Remplacer maintenant si :
  • Un test SMART long montre une erreur de lecture
  • ZFS marque le périphérique faulted ou montre des erreurs permanentes
  • 197 (pending) persiste après le test long ou augmente
  • 198/187 augmente (non-correctibles) en charge normale
  • NVMe Critical Warning est non nul ou les erreurs média augmentent
• Planifier le remplacement si :
  • Les secteurs réalloués (5) sont non nuls et augmentent lentement
  • Le pourcentage utilisé d’un SSD est élevé et vous approchez des règles de cycle de vie
• Ne pas remplacer encore si :
  • Seuls les CRC augmentent et les compteurs média sont propres → corriger câblage/backplane/HBA
  • Seuls des attributs bruyants font peur (raw read error rate) sans corroboration

Checklist C: Building a sane SMART monitoring setup on Proxmox

1. Assurez-vous que smartmontools est installé et que smartd tourne.
2. Utilisez des IDs de périphérique stables pour le suivi (symlinks by-id).
3. Collectez un petit sous-ensemble d’attributs et archivez-les (un snapshot quotidien suffit).
4. Alarmez sur le changement, pas sur l’existence :
   • delta(197) > 0 → pager
   • delta(198) > 0 → pager
   • delta(5) > 0 → ticket
   • delta(199) > 0 → ticket ; pager si rapide et corrélé à des erreurs I/O
5. Planifiez des tests SMART longs étalés sur les disques et les nœuds.
6. Vérifiez que les scrubs ZFS ou Ceph sont exécutés et revus.

FAQ

1) If SMART says PASSED, can I ignore Proxmox warnings?

Non. « PASSED » signifie souvent « n’a pas franchi le seuil catastrophique du fournisseur ». Des secteurs pending et des non-correctibles peuvent exister alors que l’état global passe.

2) Which single HDD SMART attribute is most predictive?

Current_Pending_Sector (197) est celui qui fait changer les décisions le plus vite. Il représente des secteurs illisibles maintenant, pas un remappage historique.

3) Are reallocated sectors always a reason to replace?

Pas toujours immédiatement. Un petit nombre réalloué stable peut durer longtemps. Un compteur qui augmente est votre plan de remplacement qui s’écrit.

4) What does UDMA CRC error count mean in practice?

Corruption de données sur la liaison entre le disque et le contrôleur. Pensez câble, backplane, expander, port HBA ou bruit d’alimentation. Ce n’est souvent pas la faute du disque.

5) Why does ZFS show checksum errors when SMART looks fine?

Parce que SMART mesure la vue interne du disque. ZFS valide les checksums de bout en bout et peut détecter la corruption causée par la RAM, le HBA, les câbles ou des bugs firmware.

6) Should I run SMART long tests on production hosts?

Oui, mais étalez-les. Un test long SMART coûte moins cher qu’une reconstruction surprise en période de pointe. Si l’impact de performance est inacceptable, c’est un problème de capacité/planification, pas de SMART.

7) For NVMe, what should I alert on?

Alertez sur un Critical Warning non nul, une augmentation des Media and Data Integrity Errors, et des sauts soudains de resets/timeouts dans les logs noyau. Le Percentage Used sert à la planification du cycle de vie.

8) Proxmox can’t read SMART behind my RAID controller. What now?

Utilisez les outils du contrôleur pour la santé des disques, ou passez en mode HBA/IT pour que l’OS voie les disques directement. Si vous ne pouvez pas observer la santé par disque, vous êtes aveugle — à grande échelle, c’est un choix avec des conséquences.

9) How do I decide between “replace disk” and “fix cabling”?

Si 5/197/198/187 (ou erreurs média NVMe) augmentent, c’est le disque. Si seuls les CRC/resets de lien augmentent et que les compteurs média sont propres, c’est le chemin.

10) Does high temperature mean imminent failure?

Pas nécessairement imminent, mais cela raccourcit la durée de vie et peut induire des erreurs et du throttling. Traitez une température élevée persistante comme un bug de fiabilité : flux d’air, courbes de ventilateurs, poussière et conception du châssis.

Conclusion : que faire ensuite, concrètement

Quand Proxmox vous signale une alerte SMART, ne vous laissez pas hypnotiser par le « PASSED » global. Allez directement aux quelques compteurs qui prédisent réellement les ennuis : secteurs pending, non-correctibles, réallocations, erreurs média NVMe, et les compteurs de transport qui impliquent câblage et backplane.

Étapes suivantes qui rapportent immédiatement :

1. Choisissez un petit ensemble d’alertes opinions : 5/187/197/198/199 pour SATA ; critical warning/media errors/percentage used pour NVMe.
2. Suivez ces valeurs dans le temps. Alertez sur le changement, pas sur l’existence.
3. Laissez ZFS/Ceph juger de l’intégrité et utilisez SMART comme système d’alerte précoce.
4. Notez vos règles de décision de remplacement et appliquez-les. L’objectif est la cohérence, pas l’héroïsme.

Votre pile de stockage n’a pas besoin que vous soyez optimiste. Elle a besoin que vous soyez ennuyeux, systématique et légèrement méfiant vis-à-vis des tableaux de bord.