Um setor defeituoso indica um disco com falha?

Question

Meu sistema Ubuntu 13.10 tem apresentado um desempenho muito ruim no último dia. Observando os registros do kernel, parece que o disco SATA de 3 TB com mais de 1 TB está tendo problemas com um setor específico:

Nov  4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov  4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov  4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov  4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov  4 20:54:04 mediaserver kernel: [10893.039202]          res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov  4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: status: { DRDY ERR }
Nov  4 20:54:04 mediaserver kernel: [10893.039211] ata4.01: error: { UNC }
Nov  4 20:54:04 mediaserver kernel: [10893.148527] ata4.00: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180322] ata4.01: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180345] sd 3:0:1:0: [sdc] Unhandled sense code
Nov  4 20:54:04 mediaserver kernel: [10893.180349] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  4 20:54:04 mediaserver kernel: [10893.180356] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180359] Sense Key : Medium Error [current] [descriptor]
Nov  4 20:54:04 mediaserver kernel: [10893.180371] Descriptor sense data with sense descriptors (in hex):
Nov  4 20:54:04 mediaserver kernel: [10893.180373]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180384]         af 83 3f f8
Nov  4 20:54:04 mediaserver kernel: [10893.180389] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180393] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  4 20:54:04 mediaserver kernel: [10893.180396] sd 3:0:1:0: [sdc] CDB:
Nov  4 20:54:04 mediaserver kernel: [10893.180398] Read(16): 88 00 00 00 00 00 af 83 3f f8 00 00 00 08 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180412] end_request: I/O error, dev sdc, sector 2944614392
Nov  4 20:54:04 mediaserver kernel: [10893.180431] ata4: EH complete

O arquivo kern.log tem cerca de 33 MB, na maior parte do tempo, está cheio do erro acima repetido e o setor não parece ser diferente nas mensagens repetidas.

Atualmente, estou executando o seguinte comando no disco, agora não montado, para testar e tentar resolver os problemas que o disco possa ter. Estou por volta das 12hrs e espero que leve outras 24/48 horas, já que o disco é tão grande:

e2fsck -c -c -p -v /dev/sdc1

Minha pergunta é: essa unidade está falhando ou estou vendo um problema comum aqui? Eu estou querendo saber se há algum ponto para eu reparar ou ignorar setores defeituosos e se devo substituir o disco na garantia enquanto ainda está coberto. Meu conhecimento do comando acima é um pouco deficiente, por isso estou cético quanto a se vai ajudar ou não.

Atualização rápida!

O e2fsck finalmente terminou após 2 dias com muitos 'blocos de reclamação múltipla no inode'. Tentar montar o sistema de arquivos resultou em um erro, forçando-o a retornar para somente leitura:

Nov 11 08:29:05 mediaserver kernel: [211822.287758] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Nov 11 08:29:05 mediaserver kernel: [211822.301699] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

Tentando ler o setor manualmente:

sudo dd count=1 if=/dev/sdc of=/dev/null skip=2944614392
dd: reading ‘/dev/sdc’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.73077 s, 0.0 kB/s

Tentando escrever para ele:

sudo dd count=1 if=/dev/zero of=/dev/sdc seek=2944614392
dd: writing to ‘/dev/sdc’: Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.87869 s, 0.0 kB/s

Em ambas as contagens, o Reallocated_Sector_Ct permaneceu 0.

A unidade entra em um estado de suspensão com bastante frequência. Agora estou pensando que isso poderia ser um problema no sistema de arquivos? Eu não sou 100%.

    

Answer 1

Os setores defeituosos são sempre uma indicação de um disco rígido com falha, na verdade, no momento em que você vê um erro de E / S como esse, provavelmente já perdeu / corrompeu alguns dados. Faça um backup se você não tiver um, execute um teste de auto-teste smartctl -t long /dev/disk e verifique os dados SMART smartctl -a /dev/disk . Consiga um substituto se puder.

Os setores defeituosos não podem ser reparados, apenas substituídos por setores de reserva, o que prejudica o desempenho do HDD, já que eles exigem buscas adicionais para os setores de reserva sempre que são acessados. Marcar esses setores como ruins na camada do sistema de arquivos ajuda, já que eles nunca serão acessados; no entanto, é difícil determinar quais setores já foram realocados pelo disco, então é provável que o sistema de arquivos não saiba como evitar a região afetada.

    

Answer 2

Para fazer o drive para realocar os setores, geralmente você precisa escrever algo neles. No entanto, dd ( D isk D estroyer) nem sempre funciona, e é muito inseguro: se você confundir as opções skip e seek , você pode facilmente atirar no próprio pé por skip ping os N primeiros blocos de /dev/zero e escrever um bloco daquele "deslocamento" sobre o setor 0 do seu disco disco .

Se você realmente sabe que quer forçar o setor a ser sobrescrito com zeros, você deve usar hdparm :

% sudo hdparm --read-sector 833192656 /dev/sda
/dev/sda:
reading sector 833192656: FAILED: Input/output error

Sim, o setor 833192656 também falhou nos testes inteligentes. Para escrever zeros, use --write-sector :

% sudo hdparm --write-sector 833192656 /dev/sda
/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Como medida de segurança, hdparm realmente não escreve nada, a menos que você passe a opção --yes-i-know-what-i-am-doing para hdparm :

% sudo hdparm --yes-i-know-what-i-am-doing --write-sector 833192656 /dev/sda
/dev/sda:
re-writing sector 833192656: succeeded
% sudo hdparm --read-sector 833192656 /dev/sda                              

/dev/sda:
reading sector 833192656: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[      ... more zeroes here...        ]
0000 0000 0000 0000 0000 0000 0000 0000

%

    

Answer 3

Não, os setores defeituosos não são sempre uma indicação de uma unidade com falha. Às vezes, se uma gravação está em andamento no momento de uma falha de energia, os dados no setor serão corrompidos, resultando em um erro ao tentar lê-lo. A tentativa de escrever novos dados para o setor pode funcionar muito bem, já que não há nada de errado com isso.

Você pode executar badblocks -n na unidade para ler e reescrever todos os setores, ou no seu caso, já que você já sabe o número do setor em questão, você pode usar dd para escrever zeros nele. Você pode verificar as estatísticas do SMART com smartctl -a . Você deve ver a contagem realocada pendente indicar quantos setores falharam na leitura e, depois de tentar gravar o setor, essa contagem diminuirá. A contagem do setor realocado pode subir, caso em que foi fisicamente ruim e foi remapeado para o pool de reposição, e isso pode ser um sinal de que a unidade está a caminho. Se não, então foi apenas embaralhado e deve estar bem agora.

Tente ler o setor primeiro:

dd count=1 if=/dev/sda of=/dev/null skip=nnnn

Se isso falhar, você tem o número correto, então você pode zerar com:

dd count=1 if=/dev/zero of=/dev/sda seek=nnnn

Verifique novamente se você digitou o comando exatamente antes de digitar "Enter".