Smartctl, quand s'inquiéter ?

Support Debian
#1

Bonjour à tous !

J’ai commencé à utiliser smartctl il y a peu (inconscient que j’étais !), et du coup je n’ai pas trop de points de repères fiables. Ceci dit je trouve que les Raw_Read_Error_Rate, Seek_Error_Rate et Hardware_ECC_Recovered sont anormalement hauts (et augmentent assez rapidement).
Soit dit en passant, le disque passe quand même le health-test (smartctl -H /dev/sda) et le short self-test (smartctl -t short /dev/sda).

D’où ma question, à partir de quand dois-je m’inquiéter de ces valeurs ?

# smartctl -iA /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     MAXTOR STM3250310AS
Serial Number:    6RY1FBTL
Firmware Version: 3.AAC
User Capacity:    250 059 350 016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Wed Mar 31 08:19:36 2010 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   116   099   006    Pre-fail  Always       -       108388028
  3 Spin_Up_Time            0x0003   097   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2326
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   079   060   030    Pre-fail  Always       -       85390772
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       5171
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   020    Old_age   Always       -       2083
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       364
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   055   045    Old_age   Always       -       32 (Lifetime Min/Max 22/32)
194 Temperature_Celsius     0x0022   032   045   000    Old_age   Always       -       32 (0 15 0 0)
195 Hardware_ECC_Recovered  0x001a   078   049   000    Old_age   Always       -       78551679
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 TA_Increase_Count       0x0032   100   253   000    Old_age   Always       -       0

Édit : la température me semble un peu haute aussi.

Et je viens de m’apercevoir que le disque n’est pas dans la base de données de SMARTctl, et dans leur FAQ ils indiquent que ça peut être source de raw values incorrectes. Ça viendrait vraiment de là ?

#2

Je vois que tu utilises un Maxtor…

Perso, les seuls disques qui m’ont claqué dans les pattes c’est justement Maxtor (2 disques morts dont un des deux qui s’est dégradé tellement rapidement que je n’ai rien vu venir et j’ai été obligé d’utiliser la méthode “congélateur” pour récupérer mes données).
Et comme tu as pu le voir dans mon autre post, mon Seagate actuel est en train de faire la même. Bizarre, non, sachant que Seagate a racheté Maxtor il y a peu ?

Sinon, ton Reported_Uncorrect est lui aussi bizarre.

Concernant les valeurs brutes erronées, ça m’étonnerait beaucoup : mon Seagate est dans la base, et a le même comportement. Ça tient plus à la qualité (lire : le manque de…) du disque.
Pour la température, 32° tu trouves ça élevé ??

Bref, ce qui se passe réellement c’est que le firmware arrive à corriger les erreurs pour le moment. Jusqu’au jour où…

Un conseil : évite de mettre des données importantes sur ce disque, et à l’avenir fais le “sacrifice” de quelques euros supplémentaires pour te payer un disque correct (au hasard : Western Digital). La différence de prix est très faible et vaut largement la différence de qualité, et la sérénité qui va avec.

#3

Bon, donc ça tient tant que ça à la qualité de construction alors.
Pour mes données, pas d’inquiétude, tout est backup régulièrement sur un Western Digital externe justement :wink: Ceci dit j’espère qu’il préviendra quand même un peu avant de lacher, j’ai mon système dessus et pas de disque de remplacement sous la main (ni de sous pour lui trouver un remplaçant d’ailleurs).

Merci pour ton retour d’expérience en tout cas, c’est bien noté et dès que je peux me le permettre (vivement les salaires !) je change de crêmerie pour une plus huppée.

Édit : ah oui, et 32°C ça me paraît pas aberrant dans mes conditions (chauffage par le sol, il fait 25°C dans ma piaule en plein hiver), mais j’avais cru lire que l’optimum pour un disque c’était plutôt dans les 20~25°C…

#4

Je déterre ce sujet pour vous faire part d’infos supplémentaires que j’ai dénichées à propos des disques Seagate / Maxtor, et leurs étranges valeurs SMART (mon nouveau PC est livré avec un Seagate ayant ces valeurs aberrantes et je commençais à croire que j’avais la poisse).

Pour faire vite, il s’avère que Seagate stocke dans les valeurs brutes, pour le Raw_Read_Error_Rate / Seek_Error_Rate / Hardware_ECC_Recovered, non pas le nombre d’erreurs mais à priori un mélange du nombre d’erreurs et du nombre d’accès (les 48 bits de la valeur SMART étant séparés en deux groupes).

Résultat : il est « normal » de voir ces valeurs augmenter rapidement, c’est juste signe que le disque est utilisé.
Il n’y a donc pas à s’inquiéter (selon le support technique de Seagate) tant que le disque passe les self-tests SMART (longs et courts).
Là où il faut aussi s’inquiéter, c’est lorsque les autres valeurs habituellement à 0 commencent à augmenter, notamment Reallocated_Sector_Ct / Reallocated_Event_Count qui indiquent que des secteurs défectueux ont été réalloués automatiquement.

Franchement, ça aurait été compliqué de faire comme tous les autres constructeurs, et de présenter des valeurs cohérentes aux utilisateurs ? Pfff…

Source principale :
forums.seagate.com/t5/Internal-A … 2318#M8732
forums.seagate.com/t5/Internal-A … 772#M10709

Si le sujet vous intéresse réellement, allez également voir les discussions usenet citées dans ces deux messages (il détaille la méthode qu’il a utilisée pour parvenir à ces conclusions). Beaucoup de conjectures, certaines étant validées expérimentalement, d’autres restant de simples hypothèses faute d’avoir suffisamment d’informations (car bien évidemment, Seagate comme tout « bon » constructeur évite soigneusement de fournir des explications précises).

#5

À la bonne heure :slightly_smiling: