Tempo extremamente longo para um ext4 fsck

3

O problema que estou tendo é o tempo extremamente longo que o fsck está tomando. Eu fiz pesquisas no Google, mas não consegui encontrar nada que resolvesse o problema.

O comando que estou executando é sudo fsck.ext4 -vc /dev/sdb1 .

Eu tenho um disco rígido SATA de 200GB que possui alguns setores defeituosos. É compatível com SMART, no entanto, a SMART de alguma forma não é capaz de remapear os setores. O comando que estou executando vai verificar se há setores defeituosos e adicioná-los à lista de bloqueios inválidos. No entanto, aqui está a saída até agora:

e2fsck 1.42 (29-Nov-2011)
Checking for bad blocks (read-only test): 1.95% done, 11:53:24 elapsed. (1657/0/0 errors)

Nesse ritmo, provavelmente levará cerca de um mês.

Agora não me diga "Seu disco rígido está muito velho e vai falhar logo blá blá blá". Eu só quero adicionar os blocos ruins para a lista de badblocks. O disco rígido não está desenvolvendo novos setores defeituosos.

Minha máquina tem um i3 quad-core com 8GB de RAM. Meu uso da CPU está abaixo de 10% e cerca de 1,5 GB da RAM é usado. Nada é paginado.

O disco que estou verificando tem um sistema de arquivos ext4 recém-criado sem nada nele.

Eu apenas não entendo porque levará 1 mês para criar um disco e listar os blocos defeituosos. Algo está definitivamente errado aqui. Algum conselho?

    
por fuzzyhair2 09.06.2013 / 15:34

1 resposta

1

A SMART não remapeia setores, apenas detecta e registra erros. Os setores defeituosos são remapeados automaticamente quando gravados. Você pode fazer isso com dd ou hdparm --write-sector .

Se a sua unidade não puder fazer o remapeamento do setor porque ficou sem setores de reserva, você deve estar um passo antes do pânico.

Remapeando-os no sistema de arquivos não faz muito sentido.

Se hdparm -t /dev/sdb lhe der resultados razoáveis, você poderá executar badblocks sozinho (com -s ) para verificar se é mais rápido se for executado diretamente e executá-lo através de strace se não for mais rápido para obter uma impressão de onde o problema de desempenho é resultado.

Talvez existam certas áreas no disco que causam muitas tentativas de leitura.

    
por 09.06.2013 / 16:50