mercredi 07 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de skc :

Journal : SMART: Self-Monitoring, Analysis, and Reporting Technology

Posté par Sébastien Koechlin () le 03 septembre 2007
0
SMART est une norme maintenant implantée dans pratiquement tous les disques durs qui lui permet de faire une analyse de sa bonne santé. La page de Wikipedia en anglais: http://en.wikipedia.org/wiki/S.M.A.R.T. vous donnera pas mal d'informations, ce journal a pour simple but de présenter les bases de façon succincte.

Sommaire:
1. Lire les attributs SMART d'un disque
2. Signification de différents champs remontés par attribut
3. Interpréter la santé d'un disque avec les attributs

1. Lire les attributs SMART d'un disque
La commande smartctl est classiquement utilisé sous OPALPAG GNU/Linux et sous d'autres OS (*BSD) pour lire les attributs SMART d'un disque dur. Il doit être lancé sous l'utilisateur root. Pour un disque PATA, on utilise smartctl -A /dev/hd[a-t], pour un disque SATA il faut ajouter une option smartctl -A -d ata /dev/sd[a-z] pour ne pas confondre avec du SCSI.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  1 Raw_Read_Error_Rate     0x000f   105   097   006    Pre-fail  Always       -       47916578

  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0

  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       3

  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       1

  9 Power_On_Hours          0x0032   062   062   000    Old_age   Always       -       33613

190 Unknown_Attribute       0x0022   063   058   045    Old_age   Always       -       673447973

198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0


2. Signification de différents champs remontés par attribut
Chaque attribut est identifié par un numéro, colonne ID#. Pour rendre les choses lisible, smartctl donne le nom correspondant dans la colonne ATTRIBUTE_NAME. Certains attributs sont propre au constructeur et n'ont pas de nom définis (#190 dans l'exemple).

Le disque dispose de valeurs bruts qui enregistrent une situation ou une évolution; par exemple le nombre de démarrage du disque, le nombre d'erreur d'un certain type, la température, le temps de positionnement de la tête. C'est la colonne RAW_VALUE.

Cette valeur brute n'est normalement pas utilisable directement parce que parfois c'est une valeur basse qui est inquiétante, parfois c'est une valeur haute, parfois c'est simplement une valeur qui va être combiner avec d'autres pour interpréter la situation. Le disque fait donc une normalisation appelée VALUE qui varie entre 0 et 255. Détail cocasse source de confusions inépuisables, ce sont les valeurs basses qui indiquent un problème. Plus la valeur est basse, plus il faut s'inquiéter.

A partir de quand faut-il s'inquiéter ? Le fabriquant a choisi une limite à la construction du disque que l'on trouve dans la colonne THRESH. Ceci est une constante qui indique le seuil limite en dessous duquel le disque donne des signes de faiblesse et à partir de laquelle il faut remplacer le disque.

Parce que vous ne surveillez pas toutes les 3 minutes les attributs du disque, et que certains indicateurs ne sont pas strictement décroissants (la température ou les taux d'erreur augmentent et diminuent régulièrement), le disque enregistre la pire valeur jamais atteinte, c'est à dire la valeur la plus faible. C'est la colonne WORST.

3. Interpréter la santé d'un disque avec les attributs
Dans la pratique, j'ai toujours perdu mes disques avant que SMART ne s'inquiète. Les valeurs de THRESH sont parfois très largement optimistes. Les deux indicateurs que je surveille pour juger de la bonne santé d'un disque sont #5 (Reallocated_Sector_Ct) et #197 (Current_Pending_Sector).

La valeur brute de Current_Pending_Sector indique le nombre de secteurs qui vont probablement être ré-alloués. Cela signifie que le disque n'a pas réussi à lire le secteur en question, et que si vous écrivez dessus, il utilisera très probablement un secteur de réserve à la place. Au passage, félicitation, vous avez perdu 512 octets de donnée, vous aviez du RAID j'espère ? Une fois le secteur remappé sur un secteur de réserve, cette valeur est décrémenté. Je ne l'ai jamais vu dépasser la valeur 2, c'est un état transitoire.

La valeur brute de Reallocated_Sector_Ct indique le nombre de secteurs qui sont déclarés inutilisables sur le disque et qui ont été remappés sur un secteur de réserve. Cette valeur est strictement croissante, elle augmente au fur et à mesure que les secteurs sont perdus. Certains disques tournent sans problème avec quelques secteurs défectueux, le compteur reste à une valeur constante (valeur 1 depuis des années dans l'exemple ci-dessus pour un disque qui tourne depuis #9 (Power_On_Hours) 33613h soit 3.8 ans). La grosse inquiétude est à avoir lorsque cette valeur est croissante; tous les disques que j'ai perdu depuis que je contrôle les attributs SMART avaient un compteur brut qui augmentait de une ou plusieurs unités par jour. Même avec plus d'une centaine de secteurs remappés, la valeur normalisée VALUE restait largement au dessus du THRESH, le disque était donc considéré comme sain, malgré les dizaines de Ko de données perdues (merci le RAID).

> Lire le journal (15 commentaires, moyenne: 3,9).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Excellent journal!

Posté par Axel () le 03/09/2007 à 10:18. (lien). Évalué à 10.

Il mérite même d'être en première page.

En pratique

Posté par Sytoka Modon (page perso, ) le 03/09/2007 à 10:36. (lien). Évalué à 5.

> Dans la pratique, j'ai toujours perdu mes disques avant que SMART
> ne s'inquiète

Je suis un peu au même point, du coup, j'avoue que je ne regardes plus trop ce que me dit SMART et il m'arrive de ne plus l'installer sur les postes pour cette raison.

Car c'est bien d'avoir plein de chiffre et de pouvoir faire des graphes avec mais en pratique, si on n'a aucun critère pour remplacer un disque avant qu'il lache, cela ne sers pas à grand chose. A moins d'être suffisament riche pour remplacer les disques en n'ayant pas de critère obectif pour le faire...

  • [^]Re: En pratique

    Posté par niconoe () le 03/09/2007 à 10:51. (lien). Évalué à 4.

    > A moins d'être suffisament riche pour remplacer les disques en n'ayant pas de critère obectif pour le faire...

    Mouais... perso, j'ai l'impression que les disques claquent surtout soit au début de leur vie (prob. de production) soit bien plus tard quand ils ont fait leur temps...

    Bref, je suis pas convaincu qu'en remplaçant un disque qui à 2 ans et fonctionne nickel par un neuf, on risque moins de casse...

    Y à rien à faire, une bonne politique de backup c'est pas près de devenir superflu...

    • [^]Re: En pratique

      Posté par Jeff_ (Jabber id, ) le 03/09/2007 à 11:57. (lien). Évalué à 2.

      oué et un formatage bas niveau + tests intensifs lors de la première install et tous les ans attention toutefois : même si smart peut être désactivé sans pb (fiabilité douteuse) certains outils de diagnostic s'appuient dessus et/ou refusent de se lancer/fonctionner pleinement s'il n'est pas activé... dans le doute : l'activer avant toute opération de maintenance sur disque.

      --
      "L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]

      • [^]Re: En pratique

        Posté par tuiu pol (Jabber id, ) le 05/09/2007 à 15:11. (lien). Évalué à 3.

        oué et un formatage bas niveau + tests intensifs lors de la première install et tous les ans


        Heu c'est pas super réaliste. Déjà si les utilisateurs pouvaient penser à sauvegarder leurs données ce serait miraculeux, je ne me vois pas conseiller de tout simplement effectuer un formattage bas niveaux tous les ans (remarque que si tu as l'Autre(Tm) d'installer ça peut être un bon réflexe)

        • [^]Re: En pratique

          Posté par Jeff_ (Jabber id, ) le 06/09/2007 à 15:13. (lien). Évalué à 2.

          c'est clair que je parle de si on a l'Autre (belle appellation au passage)... ou lorsqu'on change d'os.

          --
          "L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]

      • [^]Re: En pratique

        Posté par Nicolas Boulay () le 06/09/2007 à 12:13. (lien). Évalué à 3.

        J'ai peur aussi des erreurs lattentes. Genre les fichiers qui dorment des années sans lecture donc sans detection d'erreurs possible.

        J'ai l'impression qu'il faudrait au moins une fois par an lancé un :
        $ dd if=/dev/hdxx of=/dev/null bs=1M

        histoire que le système lise et corrige toutes les erreurs (on appelle ça du scrubing).

        C'est beau les systèmes de correction d'erreurs mais cela ne marche que si il y a lecture-correction-écriture assez souvent !

        Mais je ne suis pas sur que mon dd, réécrivent les secteurs jugé "limites" (en gros avec des erreurs mais récupérables et transferable dans un autre cluster)

        • [^]Re: En pratique

          Posté par regdub () le 12/09/2007 à 17:56. (lien). Évalué à 1.

          Les problème des erreurs latentes m'intéresse aussi pour ce qui est des photos par exemple.

          Je ne pensais pas qu'une lecture pouvait entraîner une écriture.
          Quand tu dis le système, c'est linux ou c'est le firmware du disque ?
          D'après ta conclusion, c'est au niveau du disque, on dirait.

          A la limite, tu suggérerais presque de faire des "cp .tmp && mv .tmp " ?

  • [^]Re: En pratique

    Posté par herodiade () le 03/09/2007 à 11:09. (lien). Évalué à 5.

    À ce sujet, vous pouvez relire les études et statistiques menée par Google et CMU concernant les pannes sur de très larges échantillons de disques durs :
    http://linuxfr.org/2007/02/21/22103.html

    Ces études confirment vos impressions : S.M.A.R.T. n'anticipe que rarement une panne prochaine du disque (mais lors que S.M.A.R.T s'alarme, il y a de fortes probabilités pour que le disque ne tienne plus longtemps).

    • [^]Re: En pratique

      Posté par Dabowl_92 () le 03/09/2007 à 11:19. (lien). Évalué à 9.

      Juste un peu avant que ton clavier ne se blo

Question bête...

Posté par Gyro Gearllose () le 03/09/2007 à 11:34. (lien). Évalué à 2.

J'avais entendu dire qu'activer le SMART dans le BIOS, de façon à s'en servir, ralentissait, parfois considérablement, le(s) disque(s) dur(s) de la machine. Qu'en est-il réellement ?
Vu ce qui est dit plus haut, j'ai presque envie de me dire que de toutes façons, il n'y a que 11 choix possibles :
01) smart ne réduit pas la vitesse des disques mais est inutilisable, car les informations remontées ne sont pas "fiables"
10) smart réduit la vitesse des disques, et donne des informations de toutes façons inutilisables.
11) désactiver smart ne fera pas de mal, puisque les informations qu'il véhicule sont difficilement utilisables, et au mieux, ça accélérera les accès disques.
Et vous, qu'en pensez-vous ?
D'autant que pour une machine personnelle, et à partir du moment où aucune donnée sensible ne reste sur les disque durs, mais est systématiquement sauvegardée (hum, hum), la perte d'un disque n'est pas gênante (sauf pour le porte monaie)...

--
All articles which are excluded shall be deemed included
Tous les articles exclus sont considérés inclus
--Brian de Palma in Phantom of the Paradize

  • [^]Re: Question bête...

    Posté par regdub () le 12/09/2007 à 17:30. (lien). Évalué à 2.

    Dommage que personne n'ait quelque chose à dire pour la vitesse.

    Ayant un filtre à poussière, il y a une donnée que je trouve utile, en tout cas, c'est la température. Celle-ci indique que le moment de nettoyer le filtre est arrivé.

smart-notifier

Posté par Raphaël SurcouF (Jabber id, page perso, ) le 05/09/2007 à 01:57. (lien). Évalué à 1.

Il existe une interface GTK+ (pour l'instant uniquement) écrite en python qui exploite justement SMART et permet d'être alerté via un popup.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0785s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !