HDD disque dur mort ?

Support Debian
#1

Bonjour à tous,

J’ai un serveur sous Debian Lenny installé sur un RAID0 logiciel.
Suite à un freeze de celui-ci j’ai trouvé ce type de messages dans mes logs :

Jun 1 09:23:46 ymir kernel: [665101.317420] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:46 ymir kernel: [665102.292349] ata1.00: configured for UDMA/133 Jun 1 09:23:46 ymir kernel: [665102.292392] ata1: EH complete Jun 1 09:23:47 ymir kernel: [665103.249763] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:49 ymir kernel: [665104.312351] ata1.00: configured for UDMA/133 Jun 1 09:23:49 ymir kernel: [665104.312403] ata1: EH complete Jun 1 09:23:49 ymir kernel: [665105.273297] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:50 ymir kernel: [665106.288348] ata1.00: configured for UDMA/133 Jun 1 09:23:50 ymir kernel: [665106.288398] ata1: EH complete Jun 1 09:23:51 ymir kernel: [665107.247159] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:52 ymir kernel: [665108.236344] ata1.00: configured for UDMA/133 Jun 1 09:23:52 ymir kernel: [665108.236395] ata1: EH complete Jun 1 09:23:53 ymir kernel: [665109.254226] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:54 ymir kernel: [665110.252346] ata1.00: configured for UDMA/133 Jun 1 09:23:54 ymir kernel: [665110.252397] ata1: EH complete Jun 1 09:23:55 ymir kernel: [665111.277839] res 51/40:00:37:61:af/40:00:3c:00:00/e0 Emask 0x9 (media error) Jun 1 09:23:56 ymir kernel: [665112.268505] ata1.00: configured for UDMA/133 Jun 1 09:23:56 ymir kernel: [665112.268556] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK Jun 1 09:23:56 ymir kernel: [665112.268605] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor] Jun 1 09:23:56 ymir kernel: [665112.268655] Descriptor sense data with sense descriptors (in hex): Jun 1 09:23:56 ymir kernel: [665112.268685] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Jun 1 09:23:56 ymir kernel: [665112.268737] 3c af 61 37 Jun 1 09:23:56 ymir kernel: [665112.268766] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed Jun 1 09:23:56 ymir kernel: [665112.268869] ata1: EH complete Jun 1 09:23:56 ymir kernel: [665112.268952] sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB) Jun 1 09:23:56 ymir kernel: [665112.269016] sd 0:0:0:0: [sda] Write Protect is off Jun 1 09:23:56 ymir kernel: [665112.269077] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 1 09:23:56 ymir kernel: [665112.269156] sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB) Jun 1 09:23:56 ymir kernel: [665112.269217] sd 0:0:0:0: [sda] Write Protect is off Jun 1 09:23:56 ymir kernel: [665112.269277] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Il semblerait que cela soit dû à un des disques du RAID. J’ai depuis remarqué que lors de gros transferts la charge montait jusqu’au plantage (>8 ; et oui c’est pas une grosse machine :slightly_smiling:).

Avec smartctl j’obtient ceci sur mon /dev/sda :

[code]# smartctl -l selftest /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright © 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Short offline Completed: read failure 20% 2769 151485589[/code]

Il semble donc que ce disque soit en phase terminale, qu’en pensez-vous ?

Voici les infos SMART du disque :

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

=== START OF INFORMATION SECTION ===
Device Model: SAMSUNG HD103UJ
Serial Number: S13PJDWQC42659
Firmware Version: 1AA01113
User Capacity: 1 000 204 886 016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 3b
Local Time is: Mon Jun 1 20:41:12 2009 CEST

==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details.

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

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 114) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (11756) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 197) minutes.
Conveyance self-test routine
recommended polling time: ( 21) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
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 099 099 051 Pre-fail Always - 20369
3 Spin_Up_Time 0x0007 080 080 011 Pre-fail Always - 6980
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 13
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 10172
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 2770
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 099 099 000 Old_age Always - 921
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 13
13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 17897
183 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
184 Unknown_Attribute 0x0033 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 17897
188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 063 061 000 Old_age Always - 37 (Lifetime Min/Max 34/39)
194 Temperature_Celsius 0x0022 062 061 000 Old_age Always - 38 (Lifetime Min/Max 34/40)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 18982081
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 098 098 000 Old_age Always - 95
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 12
201 Soft_Read_Error_Rate 0x000a 206 001 000 Old_age Always - 19392

SMART Error Log Version: 1
ATA Error Count: 630 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It “wraps” after 49.710 days.

Error 630 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH

96 51 00 ac 96 07 e9 Error: ICRC, IDNF, ABRT, NM at LBA = 0x090796ac = 151492268

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

c8 00 08 a7 96 07 e9 08 32d+19:54:50.720 READ DMA
ec 00 00 00 00 00 a0 0a 32d+19:54:50.720 IDENTIFY DEVICE
ef 03 42 00 00 00 a0 0a 32d+19:54:50.720 SET FEATURES [Set transfer mode]
ec 00 00 00 00 00 a0 0a 32d+19:54:49.320 IDENTIFY DEVICE

Error 629 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH

40 51 00 ac 96 07 e9 Error: UNC at LBA = 0x090796ac = 151492268

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

c8 00 08 a7 96 07 e9 08 32d+19:54:47.790 READ DMA
ec 00 00 00 00 00 a0 0a 32d+19:54:47.770 IDENTIFY DEVICE
ef 03 42 00 00 00 a0 0a 32d+19:54:47.770 SET FEATURES [Set transfer mode]
ec 00 00 00 00 00 a0 0a 32d+19:54:46.250 IDENTIFY DEVICE

Error 628 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH

40 51 00 ac 96 07 e9 Error: UNC at LBA = 0x090796ac = 151492268

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

c8 00 08 a7 96 07 e9 08 32d+19:54:44.750 READ DMA
ec 00 00 00 00 00 a0 0a 32d+19:54:44.740 IDENTIFY DEVICE
ef 03 42 00 00 00 a0 0a 32d+19:54:44.740 SET FEATURES [Set transfer mode]
ec 00 00 00 00 00 a0 0a 32d+19:54:43.220 IDENTIFY DEVICE

Error 627 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH

40 51 00 ac 96 07 e9 Error: UNC at LBA = 0x090796ac = 151492268

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

c8 00 08 a7 96 07 e9 08 32d+19:54:41.700 READ DMA
ec 00 00 00 00 00 a0 0a 32d+19:54:41.680 IDENTIFY DEVICE
ef 03 42 00 00 00 a0 0a 32d+19:54:41.680 SET FEATURES [Set transfer mode]
ec 00 00 00 00 00 a0 0a 32d+19:54:40.170 IDENTIFY DEVICE

Error 626 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH

40 51 00 ac 96 07 e9 Error: UNC at LBA = 0x090796ac = 151492268

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

c8 00 08 a7 96 07 e9 08 32d+19:54:38.500 READ DMA
ec 00 00 00 00 00 a0 0a 32d+19:54:38.490 IDENTIFY DEVICE
ef 03 42 00 00 00 a0 0a 32d+19:54:38.490 SET FEATURES [Set transfer mode]
ec 00 00 00 00 00 a0 0a 32d+19:54:36.850 IDENTIFY DEVICE

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Short offline Completed: read failure 20% 2769 151485589

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.[/code]

Est-ce que cela nécessite un RMA/retour SAV ?
Est-ce qu’en formatant le tout et en réinstallant le système sur les même disque les erreurs peuvent disparaitre où est-ce un problème purement matériel ?

Merci pour vos réponses !

#2

Le souci est là :

95 secteurs sont “en attente” (pending). C’est la conséquence d’erreurs non récupérables lors de la demande de lecture de ces secteurs (il est courant d’avoir des erreurs de lecture sur certains bits qui peuvent être compensées par l’ECC, cf. ligne Hardware_ECC_Recovered, mais ici ce n’est pas le cas). C’est ce qu’on appelle couramment des secteurs défectueux. Cela signifie que ces secteurs sont en attente de réallocation dans des secteurs de réserve, à l’occasion d’une future lecture réussie (on ne sait jamais) ou d’une écriture de ceux-ci. Ils passeront alors dans la ligne Reallocated_Sector_Ct.

Ça dépend. Si c’est pour du boulot sérieux, alors retour SAV sans se poser de question et remplacement. Si c’est seulement pour “jouer”, alors tu peux jouer un peu et essayer de “réparer” les secteurs défectueux en écrivant dedans, ce qui devrait forcer leur réallocation automatique. Ça a marché pour moi avec plusieurs disques. En temps normal je dirais de faire une sauvegarde des données avant, mais un assemblage RAID 0 ne contient pas de données importantes à cause de sa faible fiabilité, n’est-ce pas ?

Ce que je fais :

  • passage de badblocks en lecture seule sur tout le disque pour détecter tous les secteurs défectueux.
  • écriture et relecture des secteurs défectueux (je trouve que badblocks en écriture n’est pas très efficace, je préfère dd) ; si tu n’es pas pressé, tu peux réécrire et relire tout le disque plutôt que juste les secteurs défectueux, mais sur 1 To ça peut être très long.
  • vérification avec smartctl du nombre de secteurs “pending” restant et du nombre de secteurs réalloués.
  • on recommence jusqu’à disparition des secteurs défectueux.
  • on torture un peu le disque avec badblocks en écriture pour vérifier que de nouveaux secteurs défectueux n’apparaissent pas.

Oui, c’est un problème matériel sur le disque.

Formater, ça dépend ce que tu entends par là. Le formatage “physique” (bas niveau) ferait disparaître le problème, mais seul le fabricant en est capable. Ce qu’on appelle familèrement “formatage logique”, qui est en fait l’initialisation du système de fichiers (mkfs), ne peut rien en lui-même, sauf s’il est associé à une procédure de test des secteurs défectueux (option -c de mkfs qui fait appel à badblocks). A noter que les secteurs défectueux détectés ne seront pas corrigés mais seulement évités. AMA délicat à utiliser dans un assemblage RAID.

#3

Merci pour cette réponse très instructive !

Si je comprends bien, le fait qu’il n’arrive pas à lire ces blocs fait que lorsque je lui demande de les lire, il attend jusqu’à un certain timeout avant de poursuivre séquenciellement les autres I/O qu’il doit faire, ce qui fait monter la charge de la machine et qui la ralenti considérablement (voir la fait planter) ?

Mais alors, si le disque “sait” que ces secteurs sont défectueux, pourquoi cherche t-il encore à lire dessus plutôt que de les mettre en “quarantaine” ?

Je me laisse quelques jours pour prendre le temps de tester ta procédure : je suis tenté par un retour au SAV mais tant qu’à faire, autant tenter le coup, je n’ai rien à perdre puisque de toute façon je serai bon pour une réinstall en cas de RMA :frowning:
(D’ailleurs, à supposer que j’arrive à guérir mon disque, est-ce qu’il ne risque pas de rencontrer d’autres erreurs du fait de sa fragilité apparente/mauvaise série/mauvais montage ou autre ?)

PS : les données sont importantes mais le RAID0 ne fait pas partie de ma procédure de backup :slightly_smiling: (synchronisations régulières sur un disque externe)

#4

Parce que l’erreur de lecture n’est peut-être que transitoire, un cas limite (il suffirait qu’un bit supplémentaire soit lu correctement pour que l’ECC puisse corriger les autres bits erronés), dépendant de facteurs environnementaux comme la température, une alimentation un peu faible ou instable… Mettre un secteur temporairement illisible “en quarantaine”, ce serait prendre le risque de perdre irrémédiablement son contenu. Par conséquent l’électronique du disque ne le réalloue que lorsqu’on écrit dessus, puisque de toute façon les données précédentes, illisibles ou pas, auraient été écrasées.

C’est un risque. C’est pourquoi il faut le “torturer” un peu avant de le remettre en service. Les quelques disques que j’ai remis en état de cette façon n’ont pas eu de nouveaux secteurs défectueux, juste un secteur supplémentaire réalloué de façon transparente de temps en temps avant de devenir totalement illisible. C’est d’ailleurs ce qui devrait se passer en temps normal. Mais c’étaient des disques d’anciennes générations, de capacités de quelques dizaines de giga-octets maximum, rien à voir avec le téra-octet.

#5

Me revoilà avec mon disque sous le bras.

J’ai utilisé badblocks (qui me renvoie encore plus d’erreurs qu’avec le diagnostique SMART)

J’ai trouvé cette procédure : Bad block HOWTO for smartmontools mais elle me parait vraiment longue pour toutes les erreurs que j’ai (de plus je ne suis pas sur que ça marche sur un RAID 0 (donc avec des données réparties sur 2 disques physiques).

J’ai en désespoir de cause utilisé l’utilitaire disque de Samsung hutil (ce dernier permet d’effacer le disque dur et de faire un LLF) sans succès puisqu’au bout d’un certain temps il plante suite aux multiples erreurs.

J’ai même essayer ça : Comment défragmenter son disque dur mais ça n’a pas marché non plus !

Bref finalement j’ai entamé une procédure de RMA auprès de Samsung.
Merci PascalHambourg pour le coup de main.

#6

Tu peux essayer de regarder si les erreurs sont physiquement localisées dans une plage. Dans ce cas, tu donnes toi même la table de badblocks (enplus de sblocs qu’il trouvera. Le disque peut être utilisable. J’avais récupéré comme ça un disque ayant subi un atterrissage de tête de lecture, j’avais perdu en gros 5% du disque et la reconstruction du système de fichier avait pris 1 journée et demi mais le disque a tenu pendant 5 ans après. Je ne sais pas adapter ça sur du RAID par contre.

#7

L’utilitaire Hutil me ressortait les erreurs qu’il trouvait sous la forme :

avec “H:4” je présume la tête de lecture qui reporte l’erreur ? Auquel cas comme la valeure varie entre 0 et 4 cela semble être réparti sur l’ensemble du disque (à tel point que hutil n’arrive pas à effacer le disque :/).

Ce qui me conforte dans cette idée c’est que badblocks a trouvé des erreurs à chaque %age d’avancement du scan. Comme j’imagine qu’il fait un scan séquentiel ça semble montrer que le disque est pourri de l’intérieur :slightly_smiling:

#8

Pas surprenant que badblocks trouve plus d’erreurs que smartctl. D’une part SMART ne relève que les secteurs défectueux auxquels tu a tenté d’accéder (alors que badblocks essaie de lire tous les secteurs), d’autre part la taille de son journal est limitée. Si tu relances smartctl après badblocks, le nombre brut de Current_Pending_Sector devrait avoir augmenté (à quelle valeur ?). Combien d’erreurs badblocks a-t-il trouvées ?

Le RAID introduit une couche d’abstraction supplémentaire entre le système et le disque, donc il vaut mieux sortir le disque du RAID pour faire ces manipulations directement dessus. Les manipulations au niveau du volume RAID ou du système de fichier, qui sont encore au-dessus de la couche RAID, sont sans grand intérêt ici.

L’utilisation du résultat de badblocks pour marquer les blocs comme défectueux dans le système de fichiers est délicate à transposer en RAID, même si c’est plus facile en RAID 0 ou en mode “linear” qui n’ont pas de redondance que dans les autres formes de RAID avec redondance.

L’utilitaire Samsung ne fait rien de plus que “dd if=/dev/zero of=/dev/hdX”, c’est-à-dire écrire des zéros sur tout le disque. Ça n’a rien à voir avec un formatage de bas niveau. L’avantage de dd, c’est qu’on peut lui dire de continuer même s’il y a des erreurs et restreindre la partie à écrire pour gagner du temps si les erreurs sont localisées dans un intervalle de secteurs restreint.

Quant à la défragmentation, elle se situe au niveau du système de fichiers et est sans intérêt pour réparer un disque défectueux.

#9

Effectivement j’ai remarqué ça ; de mémoire smartctl annonçait ~300 secteurs pending.

Le problème c’est que je ne peux pas récupérer le nom des fichiers affectés par le problème (afin d’évaluer les pertes de données) : impossible de retrouver l’inode d’un fichier correspondant à un LBA en erreur car le système de fichier (ext3) n’existe que sur le volume RAID (/dev/md0 par exemple) et pas sur le disque physique.

Est-ce que dd sait écrire sur une partition “RAID” ? (ce qu’on voit dans fdisk par exemple) :

Device Boot Start End Blocks Id System /dev/sda3 488 121601 972848205 fd [b]Linux raid autodetect[/b]

Sauf qu’il sait faire un format bas niveau en plus (sauf s’il galvaude le terme ^^). D’ailleurs durant tous ces tests mon disque a commencer à “craquer” (ça donne l’impression que les têtes de lecture touchent les plateaux), ce qui ne présage rien de bon pour lui (vous savez, le râle de la mort) :confused:

Clique sur le lien :wink:

#10

Aucune importance. De toute façon si tu veux essayer de récupérer le disque il faudra écraser son contenu, donc ruiner le RAID et le système de fichiers.

dd sait écrire ou lire dans tout ce qui ressemble à un fichier, y compris un périphérique bloc : disque, partition, volume RAID ou LVM…

Je te garantis qu’il galvaude le terme. C’est écrit en toutes lettres : “ERASE HDD” (effacement du disque dur). Un formatage bas niveau n’a jamais consisté en un simple effacement, pas plus que dd ou mkfs ne peuvent remplacer fdformat pour formater physiquement une disquette.

Mais non, c’est juste le bras de tête qui fait plusieurs aller-retour à cause des tentatives multiples pour lire un secteur défectueux.