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):

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

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

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:

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

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

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:

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

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/):

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:

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:

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:

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”.

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:

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”.

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:

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:

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:

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.