Um setor defeituoso indica uma falha no disco?

Meu sistema Ubuntu 13.10 tem apresentado um desempenho muito ruim nos últimos dias. Observando os logs do kernel, parece que o disco SATA de <1 ano e 3 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 kern.logarquivo tem cerca de 33 MB, geralmente 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 desmontado para testar e tentar resolver os problemas que o disco possa ter. Eu tenho cerca de 12 horas e espero que demore mais 24/48 horas, pois o disco é muito grande:

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

Minha pergunta é: Esta unidade está falhando ou estou procurando um problema comum aqui? Gostaria de saber se há algum motivo para reparar ou ignorar setores defeituosos e se devo substituir o disco na garantia enquanto ele ainda estiver coberto. Meu conhecimento do comando acima está um pouco ausente, por isso estou cético quanto a ajudar ou não.

Rápida atualização!

O e2fsck finalmente terminou após 2 dias com muitos 'bloco (s) de reivindicação múltipla no inode'. Tentar montar o sistema de arquivos resultou em um erro, forçando-o a retornar ao modo 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_Ct0 permaneceu.

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

Os setores defeituosos são sempre uma indicação de falha no HDD; 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ê ainda não o possui, execute um autoteste smartctl -t long /dev/diske verifique os dados SMART smartctl -a /dev/disk. Obtenha uma substituição, se puder.

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

Para fazer a movimentação 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 os skipe seekopções, você pode facilmente atirar no próprio pé por skippingue os Nprimeiros blocos de /dev/zeroe escrever um quarteirão do que "compensar" sobre o setor 0 do seu disco rígido .

Se você realmente sabe que deseja forçar o setor a ser substituído por zeros, use hdparm:

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

Sim, o setor 833192656 também estava falhando nos testes inteligentes. Para escrever zeros nele, 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 salvaguarda, hdparmrealmente não escreve nada, a menos que você passe a --yes-i-know-what-i-am-doingchave 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

%

Não, setores defeituosos nem sempre são uma indicação de falha na unidade. Às vezes, se uma gravação estiver em andamento no momento de uma falha de energia, os dados no setor serão corrompidos, resultando em um erro ao tentar lê-los. Tentar escrever novos dados no setor pode funcionar muito bem, pois não há nada fisicamente errado nisso.

Você pode executar badblocks -na unidade para ler e reescrever todos os setores ou, no seu caso, como você já sabe o número do setor em questão, pode usar ddpara escrever zeros nele. Você pode verificar as estatísticas SMART com smartctl -a. Você deve ver a contagem realocada pendente indicando quantos setores falharam na leitura e, após tentar gravar o setor, essa contagem será reduzida. A contagem do setor realocado pode subir; nesse caso, era fisicamente ruim e foi remapeada para o pool sobressalente, e isso pode ser um sinal de que a unidade está saindo. 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 certo e pode zerá-lo com:

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

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