Falha no disco rígido ou mau controlador após encerramento

2

Depois de o nouveau congelar tudo com o monitor duplo pela milionésima vez, tive de cortar o poder do meu macbook pro (meados de 2010, fedora 24, disco rígido SAMSUNG HN-M500MBB). Não estava fazendo nada IO pesado apenas vendo slides com evince.

Na reinicialização, ele começa a espalhar erros sobre um setor defeituoso e apresenta erros como:

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

com ocasionalmente

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

e

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 }

Aqui está a saída smartctl depois de tentar ler alguns setores após o mau com o 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

Observe os setores pendentes ... Tanto os autotestes curtos quanto os longos relatam o mesmo setor defeituoso que o kernel.

O Hdparm estranhamente consegue ler tudo com sucesso, mas ( veja a edição abaixo ) meio que trava e diz

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

E diz isso para algo como 200 setores após o primeiro mau. Eu reescrevi alguns com hdparm - setor de escrita e eles pararam de reclamar. Agora estou fazendo um backup e pedi uma nova unidade, mas enquanto isso eu gostaria de entender o que aconteceu e talvez tentar consertar isso.

Observe que a contagem de setores realocados não está sendo aumentada depois que reescrevi alguns dos ruins, o que se soma à estranheza da coisa toda. Depois de reescrever, eles lêem e escrevem bem, como se nada tivesse acontecido, mas o firmware não parece remapear como setores defeituosos.

Alguma ideia? Devo apenas abandonar o disco?

PS. O OSX em outra partição ainda funciona bem.

EDIT: rescaldo

Depois de um backup, comecei a experimentar um pouco com o disco rígido.

Após o primeiro setor ruim, havia cerca de 150 com os mesmos problemas. Eu tentei lê-los com dd e dd_rescue e eles falharam. hdparm --read-sector trabalhado (com o erro de sentido acima) mas retornou dados inconsistentes (diferentes em cada leitura). hdparm --write-sector pareceu consertá-los, então reescrevi todos os setores com falhas.

Agora smartctl relata 0 setores pendentes e 0 realocações, ambos autotestes curtos e longos são concluídos sem erros. O Linux inicializa bem, todos os erros desapareceram.

Estou um pouco preocupado com aqueles ~ 70kb que eu matei, é um pouco complicado com o LVM para entender o que eles realmente continham. Eu joguei um par de MBs nessa área e são todos zeros, então eu tenho certeza que é um espaço vazio ou uma troca.

Ainda cedo para comemorar, mas o resultado parece promissor, atualizará a pergunta se algo novo acontecer.

    
por filippo 13.01.2017 / 10:00

0 respostas