Verificando a saúde do HD

O disco rígido do computador possui boa parte de seu mecanismo baseado em peças mecânicas, necessitando de maior manutenção. A grande maioria dos HDs é preparada para trabalhar pesado por mais de três anos, portanto seu uso massivo não é o grande problema, e sim a falta de manutenção por parte do usuários. Alguns HDs começam a apresentar falhas de leitura, gravação e até fazem cliques quando estão "morrendo" (clique no link para ver e ouvir) - mas seria engraçado se fizesse esse som junto com os drives de disquete (banda "Hard Disk and the floppys drives"):

Uma tecnologia cada vez mais presentes nos HDs é a S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology), um sistema de monitoramento de discos rígidos que detecta e antecipa falhas, através de vários indicadores de confiabilidade. No Linux, você pode utilizar a ferramenta "smartmontools", que pode ser instalada diretamente do repositório ("sudo apt-get install smartmontools"). Ela vem com dois programas: smartctl (de uso interativo) e smartd (monitoramento contínuo).

Para checar se o HD tem o SMART, primeiro deve descobrir o diretório "/dev" que aponta para o dispositivo. Para isso, execute no terminal o comando "sudo tail -f /var/log/syslog" para mostrar em tempo real quando ocorrer a conexão do seu dispositivo. Depois, execute o seguinte comando (trocando o <device> pelo dispositivo a ser testado, sda, sdc... por exemplo):

$ sudo smartctl -i /dev/<device>

Dentre várias informações, se o HD tiver o SMART, aparecerá no final:

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Para o smartctl acessar o drive, use o seguinte comando:

$ sudo smartctl -s on -o on -S on /dev/<device>

onde "-s on" liga o SMART se não estiver "enable", "-o on" desliga o "data collection" e "-S on" liga o "autosave of device vendor-specific Attributes". O comando deve retornar:

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
SMART Attribute Autosave Enabled.
SMART Automatic Offline Testing Enabled every four hours.

Para checar a saúde como um todo, use:

$ sudo smartctl -H /dev/<device>

Deverá retornar o seguinte (se não retornar, faça o backup AGORA):

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Passando do teste inicial, existem três tipo de teste que podem ser feitos no dispositivo: Short (roda testes que tem maior probabilidade de encontrar problemas, demora poucos minutos), Extended (ou Long; checagem completa do disco, demora horas) e Conveyance (identifica se houve danos durante transporte do dispositivo). Para estimar o tempo que os testes "short" e "extended" levarão, execute a primeira linha; para o teste curto, a segunda linha; e para o teste completo, a última linha:

$ sudo smartctl -c /dev/<device>
$ sudo smartctl -t short /dev/<device>
$ sudo smartctl -t long /dev/<device>

Para checar os resultados ou andamento de qualquer comando acima, execute o comando da primeira linha abaixo:

$ sudo smartctl -l selftest /dev/<device>
$ sudo smartctl -A /dev/<device>

O comando da segunda linha, com o parâmetro "-A", mostra todos os atributos suportados pelo HD e o status de cada um. Na coluna "Type", os campos marcados como "Old_age" indicam sintomas de que o HD está no final de sua vida útil, mas não significam por sí só problemas iminentes, enquanto que os mais graves são os "Pre-Fail". Na coluna "WHEN_FAILED" de um HD saudável, esta coluna fica limpa para todas as opções, indicando que o HD nunca apresentou os erros.

Para facilitar um pouco o trabalho, o script abaixo faz as verificações necessárias. Copiei, salve como um arquivo "smartctl_easy.sh" e transforme-o em um executável (chmod +x smartctl_easy.sh). Ao executá-lo, será exibido o horário previsto de término do teste (curto ou longo), para então usar o comando de verificação do resultado (sudo smartctl -l selftest /dev/):

#!/bin/bash
# Script para fazer checagem de disco

# Escolha o dispositivo
dev_name='sdc'

# Teste curto ou longo?
test_type='short'
#test_type='long'

sudo smartctl -i /dev/$dev_name
sudo smartctl -H /dev/$dev_name
sudo smartctl -t $test_type /dev/$dev_name

# Para verificar resultado, executar após o tempo informado pelo último comando
#sudo smartctl -l selftest /dev/$dev_name

Ao checar os resultados, será exibida uma lista com o teste mais recente realizado no topo. No caso de erro (status como "Completed: read failure"), aparecerá o LBA_of_first_error (Logical Block Address do primeiro erro) correspondente. Pegue esse número e multiplique por (512/4096), ou seja, divida por 8. Então, grave zero nessa posição através do seguinte comando:

dd if=/dev/zero of=/dev/sda conv=sync bs=4096 count=1 seek=LBA_dividido_por_8

Então refaça o teste rápido e veja se o erro foi eliminado. Caso apareça um novo setor defeituoso, repita o procedimento para o novo setor. Veja esse script para "facilitar" esse processo:

#!/bin/bash
# Script para gravar zero em setores defeituosos

dispositivo='sdb'
# Gravar arquivo com resultados do último teste de disco (somente linhas com mensagens)
smartctl -l selftest /dev/$dispositivo | grep "#" > erros.txt
# Gravar em array "setores" somente os "LBA_of_first_error"
mapfile -t setores < <(cat erros.txt | sed 's/^.....//' | awk '{ print $8 }')
# Para cada endereço, calcular posição correspondente e gravar zero
for (( i=0; i<${#setores[@]}; i++ )); do
	LBA=${setores[i]}
	setor=$((LBA/8))
	setor_antes=$((setor-1))
	setor_depois=$((setor+1))
	echo "Curando setor" $setor
	dd if=/dev/zero of=/dev/$dispositivo conv=sync bs=4096 count=1 seek=$setor
	dd if=/dev/zero of=/dev/$dispositivo conv=sync bs=4096 count=1 seek=$setor_antes
	dd if=/dev/zero of=/dev/$dispositivo conv=sync bs=4096 count=1 seek=$setor_depois
done
# Executar teste novamente para ver novo estado do disco
smartctl -t short /dev/$dispositivo

O número de setores defeituosos no drive (não remapeados) pode ser visto nos atributos "197 Current_Pending_Sector" e "198 Offline_Uncorrectable", onde o número de bad blocks é informado na última coluna. Em casos extremos, onde existam vários badblocks não marcados, você pode usar o truque de encher o HD com zeros, usando o comando "dd if=/dev/zero of=/dev/hda" para forçar a controladora a escrever em todos os blocos e assim remapear os setores (perdendo todos os dados, naturalmente). O número de setores defeituosos já remapeados pode ser acompanhado através dos atributos "5 Reallocated_Sector_Ct" e "196 Reallocated_Event_Count".

Uma outra forma de verificar os blocos com problemas é o programa badblocks, usado para buscar bad blocks no dispositivo. Veja esse exemplo, que investiga o dispositivo "sdb" e grava os bad blocks encontrados em um arquivo:

$ sudo badblocks -o badblocks_encontrados.dat -svn /dev/sdb

A opção "-n" realiza um teste não destrutivo, mantendo os dados originais, enquanto que "-w" destrói os dados (mas demora menos). Também é realizado um remapeamento dos bad blocks. Esse programa é ativado quando se usa a opção "-c" no programa e2fsck (se colocar o c duas vezes, é realizado um teste não destrutivo).

Veja mais informações e como configurar o "smartd" no artigo Monitoring Hard Drive Health on Linux with smartmontools e Use smartctl To Check Disk Behind Adaptec RAID Controllers.

Caso os HDs estejam em um array, deverá ser acrescentada a opção "-d megaraid,N", onde N é o "device number" do HD a ser testado. Para descobrir esse número, utilize o comando a seguir, que permite saber as informações do HD, variando o valor de N (lembrando que é o dispositivo, obtido através do comando "fdisk -l") . Busque o HD pelo seu "serial number".

$ sudo smartctl -a -d megaraid,N  /dev/sd<device>

Para verificar o status do array, utilize o comando "megactl" (discos SCSI, etc) e "megasasctl" (discos SAS). Drivers recentes megaraid podem exigir dispositivos sg ou BSD para acessar unidades físicas. Nesse caso, use " lsscsi -gs " para detectar o dipositivo "/dev/sgX" apropriado (instalar através do comando "apt-get install lsscsi", veja mais clicando no link). Para ver mais sobre Smartmontools e correção de setores ilegíveis de disco, clique no link.

Uma alternativa é a SeaTools para DOS (clique no link para um tutorial de uso). Você deverá gravar um CD com a imagem disponível no site e dar o boot com ele, e aí realizar os testes.

Verificando a consistência do sistema de arquivos

Em casos de queda de energia, desligamento incorreto do computador (sem ser via halt ou shutdown) ou defeitos físicos no disco rígido, pode acontecer de haver corrompimento de arquivos no sistema de arquivos. A ferramenta "smartmontools" permite checar a existência de "bad blocks" e outros problemas físicos. Já a ferramenta "fsck" (de "file system consistency check") é usada para verificar a consistência/integridade de um sistema de arquivos no Unix buscando erros lógicos. Em caso de falhas, o sistema automaticamente faz a leitura dos logs ou journal e compara com o estado atual. Se houverem inconsistências entre os logs e o sistema atual, o Linux tenta fazer a correção automaticamente. Mas se isso não for possível, deve-se efetuar uma verificação manual para a correção do problema através da FSCK.

Erro durante checagem de arquivos na inicialização de sistema, onde o usuário deverá digitar a senha do root para entrar no modo de manutenção usando linha de comando (prompt) em modo "single user". Verifique a partição em que ocorreu o erro e realize o fsck nela.

Erro durante checagem de arquivos na inicialização de sistema, onde o usuário deverá digitar a senha do root para entrar no modo de manutenção usando linha de comando (prompt) em modo "single user". Verifique a partição em que ocorreu o erro e realize o fsck nela.

Para descobrir o sistema de arquivos, use o comando:

$ sudo file -sL /dev/sd*

Conforme o sistema de arquivos, são utilizados os comandos do pacote e2fsprogs: efsck (ou fsck) para ext, e2fsck (ou fsck.ext2) para ext2, fsck.ext3 ou fsck.ext4 para ext3 e ext4 respectivamente. O comando fsck.vfat (ou fsck.msdos) é um link simbólico para a ferramenta dosfsck, que pertence ao pacote dosfstools, utilizado para partições formatadas em FAT16 ou FAT32. No Windows, o equivalente é o comando chkdsk, a abreviação de Checkdisk, que também pode ser utilizado para realizar exames de superfície por "bad sectors" (setores ruins), tarefa antigamente feita pelo Scandisk. Erros em partições NTFS podem ser corrigidos utilizando o comando "ntfsfix".

$ sudo fsck.vfat -pfv /dev/sdb1 # FAT32
$ sudo fsck.ext4 -pfv /dev/sdb1 # Ext4
$ sudo shutdown -r -F now # reinicia e executa fsck

Veja algumas opções do comando fsck (no geral, as três primeiras são recomendadas):

  • -p: corrige automaticamente o sistema de arquivos sem perguntar;
  • -f: força a verificação mesmo que o sistema de arquivos não esteja marcado como "sujo";
  • -v: ativa o modo verbose (exibe mais mensagens durante a execução do programa);
  • -y: assume sim para todas as questões;
  • -n: assume não para todas as questões (somente faz uma verificação de somente leitura no sistema de arquivos).

Em geral, o fsck é rodado na inicialização do sistema, quando é detectado que um sistema de arquivos está num estado inconsistente, indicando um desligamento anormal, como um travamento ou desligamento de energia. Pode-se também solicitar que o sistema efetue checagem de disco ao reiniciar usando a opção "-F" com o comando "shutdown -r" (vide acima) ou criar o arquivo forcefsck na raiz do sistema ("touch /forcefsck") e editar o arquivo /etc/default/rcS, buscando a opção "FSCKFIX" e trocando o "no" por "yes". Na inicialização seguinte, os discos serão então analisados e o arquivo /forcefsck destruído.

Caso esteja usando uma partição formatada em XFS, .Podem aparecer erros como "xfs internal error xfs_btree_check_sblock at line ..." Nesse caso, comece com o comando:

$ sudo xfs_check /dev/sdb1

Ele vai indicar os problemas encontrados - caso não tenha, retorna para a linha de comando sem imprimir nada. Para realmente corrigi-los, rode o:

$ sudo xfs_repair /dev/sdb1

Todo o processo é automático. Se não tiver os programas, instale-os através do comando "sudo apt-get install xfsprogs xfsdump". Veja um exemplo dois erros possíveis de aparecer:

agi unlinked bucket 0 is 5888 in ag 1 (inode=4200192)
 bad next unlinked 0x57663 for inode 4195171
 link count mismatch for inode 20208090 (name ?), nlink 0, counted 1

Os sistemas de arquivos são dividido em grupos de alocação, AGs. Em cada AG, existe uma lista desvinculada que é uma matriz de tabelas cujos elementos pode apontar para uma lista vinculada de inodes. Há um ponteiro próximo desvinculado (bad next unlinked) em cada inode. A lista é usada para representar inodes não encadeados (inodes removidos de diretórios), mas ainda são referenciados por processos. Se não houve uma desmontagem limpa, em seguida, as listas não encadeadas podem não estarem vazias e deve-se remover esses inodes. No AG#0, o elemento 5888 da matriz está apontando para inode #4200192, que foi desvinculado, mas ainda tinha referências a ele no momento em que o sistema de arquivos não foi desmontados (perda de energia, falha etc ..).

Na última linha, parece que para o diretório raiz inode #128, que tem uma contagem de 335, está encontrando 336 entradas. É como se o inode fosse excluído mas o diretório não foi atualizado corretamente.

Compartilhe o link desse texto, mas se for copiar algum trecho, cite a fonte. Valorize nosso trabalho.
Mais informações na licença de uso do site.

5 Pingbacks/Trackbacks