smartctl et smartmontools : Le guide complet de surveillance de l’état des disques Linux

smartctl est l’interface principale en ligne de commande du package smartmontools, conçue pour interroger, tester et interpréter les données S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) intégrées dans le firmware des HDD, SSD et lecteurs NVMe. Il communique directement avec le firmware du lecteur via les interfaces ATA, SCSI ou NVMe pour exposer la télémétrie de diagnostic brute que le système d’exploitation lui-même n’expose pas via les chemins d’E/S standard.

Pour tout administrateur Linux gérant du stockage physique ou virtuel — que ce soit sur un serveur bare-metal, un Serveur Dédié, ou un tableau de disques connecté localement — smartctl est l’outil le plus fiable pour détecter une défaillance imminente du lecteur avant qu’elle ne provoque une perte de données irrécupérable.

Qu’est-ce que S.M.A.R.T. et pourquoi est-ce important

S.M.A.R.T. est un système de surveillance intégré dans pratiquement tous les dispositifs de stockage grand public et d’entreprise fabriqués après 1996. Il fonctionne au niveau du firmware, suivant en permanence des dizaines de paramètres internes : taux d’erreurs de lecture/écriture, indicateurs de contrainte mécanique, niveaux d’usure NAND, comptages de secteurs réalloués et relevés thermiques.

La distinction critique que la plupart des guides manquent : les données S.M.A.R.T. sont prédictives, pas réactives. Un lecteur peut passer une vérification du système de fichiers et servir des E/S normalement tout en accumulant simultanément des secteurs réalloués à un rythme qui prédit statistiquement une défaillance dans les semaines à venir. smartctl expose cet état de dégradation caché.

S.M.A.R.T. fonctionne sur trois familles d’interfaces de stockage :

• ATA/SATA — la spécification S.M.A.R.T. originale, la plus riche en attributs
• SCSI/SAS — utilise un modèle d’attributs différent (pages de journal Informational Exceptions)
• NVMe — expose les données de santé via le NVMe Health Information Log (Log Page 0x02), avec des métriques telles que la capacité de rechange disponible, le pourcentage utilisé et les arrêts non sécurisés

Installation de smartmontools sur Linux

Le package smartmontools est disponible dans les dépôts officiels de toutes les principales distributions Linux. Installez la version appropriée à votre environnement :

Debian / Ubuntu :

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7 :

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux :

“`bash

sudo dnf install smartmontools

“`

Fedora :

“`bash

sudo dnf install smartmontools

“`

Arch Linux :

“`bash

sudo pacman -S smartmontools

“`

openSUSE :

“`bash

sudo zypper install smartmontools

“`

Après l’installation, vérifiez la version et confirmez que le support NVMe est compilé :

“`bash

smartctl –version

“`

Recherchez `NVMe` dans la liste des types de périphériques supportés. Les versions antérieures à 6.6 ont un support NVMe incomplet — sur les serveurs modernes équipés de SSD NVMe, assurez-vous d’utiliser smartmontools 7.x ou une version ultérieure.

Identification de vos périphériques de stockage

Avant d’exécuter une commande smartctl, identifiez le nœud de périphérique correct. Confondre les identifiants de périphériques sur un système multi-disques est une erreur courante et coûteuse.

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

Cela affiche les noms des périphériques ainsi que le type de transport (sata, nvme, usb), ce qui indique directement les indicateurs smartctl dont vous aurez besoin. Pour les périphériques NVMe, le nœud apparaîtra comme `/dev/nvme0`, `/dev/nvme1`, etc. — pas `/dev/sdX`.

Pour les contrôleurs RAID matériels (LSI MegaRAID, Adaptec, HP Smart Array), les lecteurs sont cachés derrière le contrôleur et nécessitent des indicateurs de pass-through explicites, couverts dans la section avancée ci-dessous.

Commandes principales de smartctl

Affichage des informations d’identité du périphérique

“`bash

sudo smartctl -i /dev/sda

“`

Cela interroge la page IDENTIFY DATA du périphérique et retourne le numéro de modèle, le numéro de série, la révision du firmware, la capacité, la taille des secteurs (512 octets logiques vs. 4096 octets physiques — important pour l’alignement), et les indicateurs de capacité S.M.A.R.T. Sur les périphériques NVMe :

“`bash

sudo smartctl -i /dev/nvme0

“`

Exécution d’une évaluation complète de l’état de santé

“`bash

sudo smartctl -H /dev/sda

“`

Retourne un verdict en une seule ligne : `PASSED` ou `FAILED`. Un résultat `FAILED` signifie que le firmware du lecteur lui-même a déterminé qu’un ou plusieurs seuils critiques ont été dépassés. Un lecteur signalant FAILED doit être traité comme défaillant — n’attendez pas de confirmation supplémentaire.

Cependant, un résultat `PASSED` ne signifie pas que le lecteur est en bonne santé. Cela signifie seulement qu’aucun seuil n’a été formellement dépassé. C’est pourquoi l’analyse des attributs bruts est essentielle.

Affichage de tous les attributs S.M.A.R.T.

“`bash

sudo smartctl -A /dev/sda

“`

C’est la commande la plus riche en informations dans une utilisation courante. Le tableau de sortie contient plusieurs colonnes qui nécessitent une interprétation précise :

La RAW_VALUE est ce que vous devriez principalement analyser. Le système normalisé VALUE/WORST/THRESH est utile pour la détection automatisée des seuils mais peut être trompeur — certains fabricants utilisent des courbes de normalisation non standard.

Sortie complète : combinaison des indicateurs

Pour une image complète en une seule commande, combinez les indicateurs d’information, de santé et d’attributs :

“`bash

sudo smartctl -a /dev/sda

“`

L’indicateur en minuscules `-a` est équivalent à `-H -i -c -A -l error -l selftest`. C’est la commande standard à exécuter lors du diagnostic d’un lecteur inconnu.

Pour une sortie encore plus détaillée incluant toutes les pages de journal :

“`bash

sudo smartctl -x /dev/sda

“`

Attributs S.M.A.R.T. critiques et comment les interpréter

Tous les attributs S.M.A.R.T. n’ont pas le même poids diagnostique. Les attributs suivants sont ceux que les ingénieurs de stockage expérimentés traitent comme des indicateurs primaires de défaillance :

Indicateurs de défaillance haute priorité

Reallocated_Sector_Ct (ID 5)

Le nombre de secteurs que le lecteur a remappés vers la zone de rechange en raison d’erreurs de lecture/écriture/vérification. Toute valeur non nulle sur un lecteur de moins de deux ans mérite une attention immédiate. Un compte en augmentation constante — même de 1 à 5 sur un mois — est un fort prédicteur de défaillance imminente. Sur les lecteurs d’entreprise, un petit nombre peut être acceptable selon les spécifications du fabricant.

Current_Pending_Sector (ID 197)

Secteurs signalés comme instables et en attente de remappage. Ces secteurs ont produit des erreurs lors des lectures mais n’ont pas encore été remappés avec succès. Une valeur non nulle ici signifie que le lecteur a activement du mal à lire les données. Si un secteur en attente est ensuite écrit avec succès, il peut être remappé ou effacé — mais le support sous-jacent est suspect.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

Secteurs qui n’ont pas pu être corrigés par l’ECC et n’ont pas pu être remappés. C’est l’attribut le plus grave. Une valeur non nulle ici signifie que des données ont déjà été perdues dans ces secteurs. La sauvegarde immédiate et le remplacement du lecteur sont la seule réponse appropriée.

Reported_Uncorrect (ID 187)

Sur les lecteurs modernes, cela compte les erreurs que l’ECC interne du lecteur n’a pas pu corriger. Des valeurs élevées indiquent une dégradation sérieuse du support.

Spin_Retry_Count (ID 10)

Pour les HDD, échecs répétés à faire tourner les plateaux à la vitesse de fonctionnement. Indique un stress mécanique sur le moteur de broche ou les roulements. Toute valeur non nulle sur un lecteur en utilisation intensive est un signal d’alarme.

Command_Timeout (ID 188)

Le nombre de commandes qui ont été abandonnées en raison d’un délai d’attente. Des valeurs élevées indiquent souvent des problèmes d’interface (câble, contrôleur ou alimentation électrique) plutôt qu’une défaillance du support — mais ils peuvent également précéder une défaillance totale du lecteur.

Attributs de surveillance secondaires

Raw_Read_Error_Rate (ID 1)

Souvent mal interprété : sur les lecteurs Seagate, cet attribut a une valeur brute très élevée par conception, car il représente un ratio encodé dans un champ de 48 bits. Une valeur brute de plusieurs millions sur un lecteur Seagate est normale. Sur Western Digital et d’autres fabricants, la valeur brute devrait être proche de zéro. Consultez toujours la documentation du fabricant avant de vous alarmer sur cet attribut.

Power_On_Hours (ID 9)

Heures de fonctionnement totales. Les HDD grand public sont généralement évalués pour 20 000–25 000 heures (environ 2–3 ans de fonctionnement continu). Les lecteurs d’entreprise sont évalués pour 55 000+ heures. Utilisez cela pour contextualiser les autres valeurs d’attributs.

Temperature_Celsius (ID 194)

La température actuelle du lecteur. La plage de fonctionnement optimale pour la plupart des HDD est de 25–45°C. Des températures soutenues au-dessus de 55°C accélèrent l’usure des roulements et la dégradation du support magnétique. Pour les SSD, la tolérance thermique est généralement plus élevée, mais des températures soutenues au-dessus de 70°C accéléreront l’usure NAND. Sur les serveurs sans flux d’air adéquat — un problème courant dans les déploiements en rack dense — la limitation thermique peut se masquer en latence d’E/S avant que l’attribut de température ne dépasse un seuil formel.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

Attributs spécifiques aux SSD suivant la consommation d’endurance NAND. Lorsque la VALUE normalisée approche la valeur THRESH, le SSD approche de son endurance d’écriture nominale. Planifiez le remplacement de manière proactive.

Power_Cycle_Count (ID 12)

Les cycles d’alimentation fréquents causent un stress mécanique sur les HDD (stationnement/déstationnement de la tête, stress du moteur de broche) et, dans une moindre mesure, un stress électrique sur les SSD. Des comptages inhabituellement élevés par rapport à Power_On_Hours peuvent indiquer un environnement d’alimentation instable.

Exécution des auto-tests de diagnostic

Les auto-tests S.M.A.R.T. sont exécutés par le firmware du lecteur lui-même, pas par le système d’exploitation. Le lecteur continue de servir des E/S pendant les tests (avec un impact mineur sur les performances), rendant ces tests sûrs à exécuter sur des systèmes en production.

Auto-test court

“`bash

sudo smartctl -t short /dev/sda

“`

Durée : généralement 1–5 minutes. Teste les composants électriques et mécaniques ainsi qu’un petit pourcentage de la surface du disque. Utile pour une vérification rapide. Consultez les résultats après la fin :

“`bash

sudo smartctl -l selftest /dev/sda

“`

Auto-test long (test étendu)

“`bash

sudo smartctl -t long /dev/sda

“`

Durée : proportionnelle à la capacité du lecteur — comptez environ 1 heure par téraoctet sur un HDD typique à 7200 RPM, et 20–60 minutes sur la plupart des SSD. Effectue une analyse complète de la surface de chaque secteur. C’est le test définitif pour détecter les secteurs défectueux sur toute la surface du support.

Surveillez la progression sans attendre la fin :

“`bash

sudo smartctl -c /dev/sda

“`

La sortie inclut un pourcentage d’avancement et une heure de fin estimée.

Auto-test de transport

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Disponible sur la plupart des lecteurs ATA. Conçu pour détecter les dommages subis lors de l’expédition ou de la manipulation physique. Vérifie les problèmes causés par des chocs mécaniques. La durée est généralement de 5 minutes. Ce test est sous-utilisé — il est particulièrement utile lors de la mise en service de nouveau matériel ou après qu’un serveur a été physiquement déplacé.

Auto-test sélectif

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

Permet de tester une plage LBA spécifique plutôt que l’intégralité du lecteur. Inestimable lorsque les vérifications du système de fichiers ont signalé des erreurs dans une région spécifique et que vous devez confirmer si le support sous-jacent en est responsable.

Surveillance de l’état de santé spécifique aux NVMe

Les lecteurs NVMe utilisent un modèle d’attributs fondamentalement différent. La commande principale de santé :

“`bash

sudo smartctl -a /dev/nvme0

“`

Champs spécifiques aux NVMe à surveiller :

• Available Spare : Pourcentage de blocs NAND de rechange restants. En dessous de 10%, un remplacement doit être planifié.
• Available Spare Threshold : Le seuil défini par le fabricant en dessous duquel le lecteur peut signaler une fiabilité dégradée.
• Percentage Used : Pourcentage estimé de l’endurance d’écriture nominale consommée. À 100%, le lecteur a atteint son TBW (Terabytes Written) nominal — il peut continuer à fonctionner, mais les garanties de fiabilité ne s’appliquent plus.
• Data Units Read / Written : E/S cumulatives en unités de 512 000 octets. Utile pour calculer la charge de travail réelle par rapport au TBW nominal.
• Media and Data Integrity Errors : Erreurs de support non récupérées ou erreurs d’intégrité des données détectées par le contrôleur NVMe. Toute valeur non nulle est sérieuse.
• Number of Error Information Log Entries : Nombre d’entrées dans le journal d’erreurs. Un compte en croissance rapide indique des problèmes persistants.
• Power State : État d’alimentation NVMe actuel — pertinent pour les charges de travail sensibles à la latence où le lecteur peut être dans un état d’économie d’énergie profond.

RAID matériel et accès en pass-through

Lorsque les lecteurs sont connectés via un contrôleur RAID matériel, le système d’exploitation voit le disque virtuel du contrôleur, pas les lecteurs physiques. smartctl nécessite un pass-through explicite pour atteindre directement le firmware du lecteur.

LSI MegaRAID :

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array (pilote hpsa) :

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID :

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

Si vous n’êtes pas sûr du type de pass-through à utiliser, smartctl peut tenter une détection automatique :

“`bash

sudo smartctl –scan

“`

Cela analyse tous les périphériques de stockage détectables et affiche le chemin de périphérique recommandé et l’indicateur de type pour chacun.

Activation et désactivation de S.M.A.R.T.

S.M.A.R.T. est activé par défaut sur pratiquement tous les lecteurs modernes. Dans de rares cas — généralement des lecteurs plus anciens ou certains environnements virtualisés — il peut être désactivé :

“`bash

sudo smartctl -s on /dev/sda

“`

Pour désactiver (non recommandé sauf pour des scénarios de test spécifiques) :

“`bash

sudo smartctl -s off /dev/sda

“`

Remarque : Dans les environnements virtualisés tels que KVM ou VMware, le pass-through S.M.A.R.T. vers les VM invitées dépend de la configuration de l’hyperviseur. Dans un environnement VPS Hosting, l’hyperviseur abstrait généralement le lecteur physique, et smartctl à l’intérieur de l’invité peut retourner des données limitées ou aucune donnée. Pour un accès S.M.A.R.T. complet, une surveillance au niveau de l’hôte physique ou un Serveur Dédié est requis.

Surveillance automatisée avec smartd

Le démon smartd est le composant de qualité production de smartmontools. Il s’exécute en arrière-plan, interrogeant périodiquement les lecteurs et exécutant des tests planifiés, puis alertant les administrateurs lorsque des seuils sont dépassés ou que des échecs de test surviennent.

Configuration de /etc/smartd.conf

La configuration par défaut surveille tous les lecteurs détectés avec des paramètres de base. Une configuration renforcée pour la production ressemble à ceci :

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

Directives clés expliquées :

Activation et démarrage de smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Vérifiez que le démon surveille activement :

“`bash

sudo journalctl -u smartd -f

“`

Configuration des alertes par e-mail

Pour que les alertes e-mail de smartd fonctionnent, le système nécessite un MTA (agent de transfert de courrier) fonctionnel. Sur les installations de serveur minimales, installez et configurez `postfix` ou `msmtp` pour le relais. Si vous utilisez une infrastructure de messagerie dédiée, envisagez d’associer les alertes smartd à un service d’Email Hosting correctement configuré pour garantir que la livraison des alertes n’est pas bloquée par les filtres anti-spam.

Comparaison des attributs S.M.A.R.T. : HDD vs. SSD vs. NVMe

Flux de travail pratique : diagnostic d’un lecteur suspect

Lorsqu’un lecteur présente des symptômes — erreurs d’E/S dans `dmesg`, corruption du système de fichiers, latence inhabituelle — suivez cette séquence de diagnostic :

Étape 1 : Confirmer la disponibilité de S.M.A.R.T.

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

Étape 2 : Vérifier le verdict global de santé

“`bash

sudo smartctl -H /dev/sda

“`

Étape 3 : Inspecter le journal d’erreurs

“`bash

sudo smartctl -l error /dev/sda

“`

Le journal d’erreurs enregistre les 5 dernières erreurs ATA avec les horodatages et les adresses LBA. Croisez les adresses LBA avec les cartes de blocs du système de fichiers en utilisant `debugfs` ou `xfs_db` pour déterminer si les erreurs affectent des structures critiques du système de fichiers.

Étape 4 : Analyser les attributs critiques

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

Étape 5 : Exécuter un test court pour une confirmation immédiate

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Étape 6 : Si le test court réussit et que les symptômes persistent, exécuter un test long pendant une fenêtre de maintenance

“`bash

sudo smartctl -t long /dev/sda

“`

Étape 7 : Examiner le journal des auto-tests pour les adresses LBA d’échec

“`bash

sudo smartctl -l selftest /dev/sda

“`

Les tests échoués rapportent le LBA de la première erreur rencontrée. Cela localise précisément l’emplacement exact des dommages sur le support.

Pièges courants et cas particuliers

Lecteurs connectés via USB : smartctl ne peut souvent pas communiquer avec les lecteurs connectés via des adaptateurs USB-to-SATA car la puce de pont USB ne transmet pas les commandes ATA. Utilisez l’indicateur `-d sat` ou `-d usb`, ou spécifiez le type de pont explicitement (par exemple, `-d usb,0x0bc2,0x2312`). L’indicateur `–scan` tentera d’identifier automatiquement le type correct.

Environnements virtualisés : À l’intérieur d’un invité KVM ou VMware, `/dev/sda` est un disque virtuel. smartctl peut retourner `Device does not support SMART` ou des données fabriquées transmises par l’hyperviseur. Ne vous fiez pas à la sortie smartctl dans l’invité pour l’évaluation de la santé physique du lecteur sur une infrastructure d’hébergement partagé.

Faux positifs sur Raw_Read_Error_Rate : Comme indiqué ci-dessus, l’encodage de cet attribut par Seagate produit des valeurs brutes alarmantes qui sont tout à fait normales. Vérifiez toujours la documentation des attributs du fabricant avant d’agir sur cette valeur.

Lecteurs derrière un RAID logiciel (mdadm) : smartctl accède directement aux lecteurs composants (`/dev/sda`, `/dev/sdb`), pas au périphérique RAID (`/dev/md0`). Surveillez chaque lecteur membre individuellement.

Espace de noms NVMe vs. contrôleur : Utilisez `/dev/nvme0` (contrôleur) pour les données de santé, pas `/dev/nvme0n1` (espace de noms/périphérique bloc). Certaines versions de smartctl acceptent les deux, mais le nœud contrôleur fait autorité pour l’accès au journal de santé.

Lecteurs qui mentent : Certains SSD grand public, en particulier les lecteurs NAND QLC de gamme inférieure, ont été documentés comme signalant des attributs S.M.A.R.T. sains jusqu’à une défaillance complète et soudaine. S.M.A.R.T. est un indicateur fort mais pas une garantie — il ne remplace pas les sauvegardes régulières.

Déploiement de smartmontools dans les environnements serveur

Pour les administrateurs gérant plusieurs serveurs physiques — tels que ceux exécutant des charges de travail sur des Serveurs Dédiés — la centralisation de la surveillance S.M.A.R.T. est essentielle. Considérez l’architecture suivante :

• Prometheus + node_exporter : Le `node_exporter` inclut un script de collecteur de fichiers texte `smartmon` qui exporte les attributs S.M.A.R.T. en tant que métriques Prometheus. Cela permet les alertes via Alertmanager et la visualisation dans les tableaux de bord Grafana.
• Nagios / Icinga2 : Le plugin `check_smart` fournit une intégration de surveillance S.M.A.R.T. pour les piles de surveillance traditionnelles.
• Scripts smartd personnalisés : La directive `-M exec` dans smartd.conf peut déclencher n’importe quel script lors d’une alerte — utile pour l’intégration avec PagerDuty, les webhooks Slack ou les systèmes de tickets personnalisés.
• Agrégation de fichiers journaux : Configurez smartd pour écrire dans syslog, puis transférez vers un agrégateur de journaux centralisé (pile ELK, Loki) pour l’analyse des tendances historiques sur une flotte.

Pour les environnements d’hébergement web utilisant des panneaux de contrôle, les déploiements de VPS avec cPanel bénéficient d’une surveillance S.M.A.R.T. au niveau de l’hôte configurée par le fournisseur d’infrastructure, car cPanel lui-même n’expose pas nativement les données de santé des lecteurs.

Liste de contrôle des points clés

Utilisez ceci comme référence pré-déploiement et opérationnelle continue :

• Installez smartmontools 7.x ou une version ultérieure pour garantir un support complet des NVMe et des SSD modernes
• Exécutez `smartctl –scan` sur le nouveau matériel pour identifier tous les lecteurs et leurs indicateurs d’interface requis
• Vérifiez d’abord le verdict de santé `-H` — un résultat `FAILED` nécessite une action immédiate indépendamment des autres attributs
• Traitez tout Reallocated_Sector_Ct, Current_Pending_Sector ou Uncorrectable_Sector_Count non nul comme un signal de défaillance — n’attendez pas que le compte augmente
• Ne vous fiez pas uniquement à Raw_Read_Error_Rate — validez par rapport à la documentation du fabricant avant de vous alarmer
• Planifiez des tests longs automatisés hebdomadaires via smartd sur tous les lecteurs en production ; des tests courts quotidiens
• Configurez les alertes e-mail de smartd et vérifiez la livraison avant de vous y fier
• Pour le RAID matériel, utilisez toujours l’indicateur de pass-through approprié — surveiller le disque virtuel n’est pas équivalent à surveiller les lecteurs physiques
• Dans les environnements virtualisés, effectuez la surveillance S.M.A.R.T. au niveau de l’hyperviseur/hôte, pas à l’intérieur des VM invitées
• Associez la surveillance S.M.A.R.T. à une stratégie de sauvegarde — S.M.A.R.T. prédit les défaillances, il ne prévient pas la perte de données
• Pour les lecteurs NVMe, surveillez Available Spare et Percentage Used en plus des comptages d’erreurs
• Sur les serveurs multi-lecteurs, intégrez smartd à une plateforme d’alertes centralisée plutôt que de vous fier à la livraison locale des e-mails

Foire aux questions

Est-ce que smartctl fonctionne à l’intérieur d’un VPS ou d’une instance cloud ?

Dans la plupart des environnements VPS, l’hyperviseur présente un périphérique bloc virtuel à l’invité. smartctl à l’intérieur de l’invité retournera soit aucune donnée, soit des données synthétisées par l’hyperviseur, qui ne reflètent pas l’état de santé réel du lecteur physique. Une surveillance S.M.A.R.T. significative nécessite l’accès à l’hôte physique. Pour une visibilité complète au niveau du lecteur, un Serveur Dédié est la solution appropriée.

Quelle est la différence entre `smartctl -a` et `smartctl -x` ?

L’indicateur `-a` affiche l’ensemble standard de données S.M.A.R.T. : informations sur le périphérique, verdict de santé, indicateurs de capacité, tous les attributs, journal d’erreurs et journal des auto-tests. L’indicateur `-x` affiche tout ce que `-a` fournit plus des pages de journal supplémentaires incluant le journal des auto-tests sélectifs, le journal des statistiques du périphérique, le journal des défauts en attente et les statistiques du périphérique ATA — fournissant une image plus complète de l’historique du lecteur. Utilisez `-x` pour des diagnostics approfondis ; `-a` pour les vérifications de routine.

Combien de temps dure un auto-test long, et est-il sûr de l’exécuter sur un lecteur en production ?

La durée dépend de la capacité et de la vitesse du lecteur : environ 1 heure par téraoctet pour un HDD à 7200 RPM, et 20–60 minutes pour la plupart des SSD. Le test s’exécute en arrière-plan dans le firmware du lecteur, et le lecteur continue de servir des E/S pendant le test. L’impact sur les performances est généralement mineur (réduction du débit de 5–15%). Il est sûr de l’exécuter sur des systèmes en production pendant les périodes de faible trafic, mais la planification pendant une fenêtre de maintenance est recommandée pour les charges de travail sensibles à la latence.

Que signifie Current_Pending_Sector non nul alors que Reallocated_Sector_Ct n’a pas augmenté ?

Le lecteur a identifié des secteurs qui produisent des erreurs de lecture mais ne les a pas encore remappés avec succès. Le remappage se produit lorsque le lecteur peut écrire dans le secteur — soit via une opération d’écriture, soit via une analyse hors ligne. Si le compte reste statique, les secteurs peuvent se trouver dans une région en lecture seule ou le lecteur peut manquer de secteurs de rechange disponibles pour le remappage. Un compte Current_Pending_Sector non nul et croissant, avec Reallocated_Sector_Ct restant stable, indique souvent que le lecteur a épuisé son pool de secteurs de rechange — une condition de défaillance critique.

Est-ce que smartctl peut détecter l’usure d’un SSD avant que le lecteur ne tombe en panne ?

Oui, pour les SSD SATA, les attributs Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) et Available_Reservd_Space (ID 232) suivent la consommation d’endurance NAND. Pour les SSD NVMe, les champs Percentage Used et Available Spare dans le NVMe Health Information Log servent le même objectif. Lorsque Available Spare tombe en dessous de son seuil ou que Percentage Used atteint 100%, le lecteur a consommé son endurance d’écriture nominale. Contrairement aux défaillances mécaniques soudaines, la dégradation par usure des SSD est progressive et hautement prévisible — ce qui en fait l’un des cas d’utilisation les plus forts pour la surveillance proactive S.M.A.R.T.