Panne de disque dur ou mauvais contrôleur après un arrêt brutal


2

Après avoir tout gelé avec le double moniteur pour la millionième fois, j'ai dû couper l'alimentation de mon macbook pro (mi-2010, fedora 24, disque dur SAMSUNG HN-M500MBB). Ne faisait rien IO lourd juste en regardant des diapositives avec evince.

Au redémarrage, il commence à cracher des erreurs concernant un secteur défectueux et à s'accrocher avec des erreurs comme:

blk_update_request: I/O error, dev sda, sector 969158669
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x3c000000 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/08:d0:08:30:c4/00:00:39:00:00/40 tag 26 ncq dma 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/28:d8:c8:2f:c4/00:00:39:00:00/40 tag 27 ncq dma 20480 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/38:e0:88:2f:c4/00:00:39:00:00/40 tag 28 ncq dma 28672 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/78:e8:08:2f:c4/00:00:39:00:00/40 tag 29 ncq dma 61440 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1.00: device reported invalid CHS sector 0

avec de temps en temps

sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 0:0:0:0: [sda] tag#19 Sense Key : Medium Error [current] 
sd 0:0:0:0: [sda] tag#19 Add. Sense: Unrecovered read error - auto reallocate failed
sd 0:0:0:0: [sda] tag#19 CDB: Read(10) 28 00 39 c4 30 08 00 00 08 00
blk_update_request: I/O error, dev sda, sector 969158669
Buffer I/O error on dev dm-2, logical block 1, async page read

et

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: irq_stat 0x40000001
ata1.00: failed command: READ SECTOR(S) EXT
ata1.00: cmd 24/00:01:0d:30:c4/00:00:39:00:00/e0 tag 6 pio 512 in
         res 51/40:01:0d:30:c4/00:00:39:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }

Voici la sortie de smartctl après avoir essayé de lire quelques secteurs après le mauvais avec hdparm:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   051    Pre-fail  Always       -       469
  2 Throughput_Performance  0x0026   252   252   000    Old_age   Always       -       0
  3 Spin_Up_Time            0x0023   086   086   025    Pre-fail  Always       -       4463
  4 Start_Stop_Count        0x0032   092   092   000    Old_age   Always       -       8099
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   252   252   051    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0024   252   252   015    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       19382
 10 Spin_Retry_Count        0x0032   252   252   051    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       980
 12 Power_Cycle_Count       0x0032   092   092   000    Old_age   Always       -       8214
181 Program_Fail_Cnt_Total  0x0022   097   097   000    Old_age   Always       -       66246139
191 G-Sense_Error_Rate      0x0022   100   100   000    Old_age   Always       -       3820
192 Power-Off_Retract_Count 0x0022   100   100   000    Old_age   Always       -       20
194 Temperature_Celsius     0x0002   064   051   000    Old_age   Always       -       32 (Min/Max 15/49)
195 Hardware_ECC_Recovered  0x003a   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   252   252   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       15
198 Offline_Uncorrectable   0x0030   252   252   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0036   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x002a   100   100   000    Old_age   Always       -       255
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       980
225 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       1583719

Notez les secteurs en attente ... Les auto-tests courts et longs signalent le même secteur défectueux que le noyau.

Hdparm parvient étrangement à tout lire avec succès mais ( voir l'édition ci-dessous ) genre de pend et dit

reading sector 969158769: SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 00 51 e0 01 11 04 00 00 a0 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00
succeeded

Et cela est dit pour environ 200 secteurs après le premier mauvais. J'ai réécrit quelques-uns avec hdparm --write-sector et ils ont cessé de se plaindre. Maintenant, je fais une copie de sauvegarde et commande un nouveau disque, mais en attendant, j'aimerais comprendre ce qui s'est passé et peut-être essayer de le réparer.

Notez que le nombre de secteurs réaffectés n’augmente pas après que j’ai réécrit quelques mauvaises, ce qui s’ajoute à l’étrangeté de l’ensemble. Après une réécriture, ils lisent et écrivent bien comme si de rien n'était, mais le micrologiciel ne semble pas les remapper en tant que secteurs défectueux.

Une idée? Devrais-je abandonner le lecteur?

PS. OSX dans une autre partition fonctionne toujours très bien.


EDIT: suite

Après une sauvegarde, j'ai commencé à expérimenter un peu avec le disque dur.

Après le premier mauvais secteur, il y en avait environ 150 avec les mêmes problèmes. J'ai essayé de les lire avec dd et dd_rescue et ils ont échoué. hdparm --read-sector travaillé (avec l'erreur de sens ci-dessus) mais renvoyé des données incohérentes (différentes à chaque lecture). hdparm --write-sector semblait les réparer alors je viens de réécrire tous les secteurs défaillants.

À présent smartctl indique 0 secteur en attente et 0 réaffectation, les auto-tests courts et longs se terminent sans erreur. Linux démarre correctement, toutes les erreurs ont disparu.

Je suis un peu inquiet à propos de ces ~ 70kb que j'ai tués, c'est un peu difficile avec LVM de comprendre ce qu'ils contiennent vraiment. J'ai largué quelques MB autour de cette zone et ce sont des zéros, alors je suis sûr que c'est soit un espace vide, soit un swap.

Trop tôt pour célébrer, mais le résultat semble prometteur, mettra à jour la question si quelque chose de nouveau se produit.


La chose étrange est que vous obtenez un temps libre erreur au lieu d'une erreur "secteur défectueux". Donc, je suppose que le microcontrôleur interne devient confus d’une manière ou d’une autre, probablement parce que la carte de réallocation est incohérente (ou parce que d’autres éléments sont incohérents). Ecrire le secteur et forcer la réallocation peut rendre la carte plus cohérente à mesure qu’elle est modifiée. Mais c'est une conjecture aveugle.
dirkt

1
Une expérience intéressante consisterait à mettre le lecteur complètement à zéro après une sauvegarde, soit directement en écrivant, soit avec un message "SECURITY ERASE" si le disque dur le prend en charge, et voir si le problème est résolu, car l’état interne doit ensuite être renouvelé.
dirkt

Ok, maintenant que j'ai une copie de sauvegarde, je vais faire quelques expériences. La première chose que j'aimerais essayer est de réécrire les "mauvais" secteurs. Étant donné que hdparm peut lire les données, savez-vous si je peux réécrire les mêmes données lues au lieu de zéros?
filippo

J'utiliserais dd ou dd_rescue pour cela au lieu de hdparm (AFAIK ne peut écrire que des zéros).
dirkt

Je les utiliserais aussi ... malheureusement, hdparm est le seul à pouvoir lire quoi que ce soit dans ces blocs :-(
filippo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.