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. Digite o comando “smartctl –scan” para ver os dispositivos que existem. 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:

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

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>

Cada um dos atributos SMART possui várias colunas, conforme mostrado pelo segundo comando:

  • ID: número do atributo (lista completa na Wikipedia).
  • ATTRIBUTE_NAME: nome do atributo SMART.
  • Valor: valor normalizado atual do atributo; valores mais altos são sempre melhores (exceto a temperatura dos discos rígidos de alguns fabricantes). O intervalo é normalmente 0-100, para alguns atributos 0-255 (de modo que 100 e 255 é o melhor, 0 é o pior).
  • WORST: pior valor (normalizado) que esse atributo teve.
  • THRESH: limite abaixo do qual o valor normalizado será considerado “excedendo as especificações” e muda a coluna “TYPE”.
  • TYPE: tipo do atributo. “Pre-fail” indica que está no período “antes da falha” e “Old_age” apenas indica desgaste.
  • WHEN_FAILED: em um HD saudável, esta coluna fica limpa para todas as opções, indicando que o HD nunca apresentou os erros.

Deve-se permanecer atento quando uma unidade que começa a obter setores defeituosos (ID 5) ou setores pendentes (ID 197) geralmente será descartada em 6 meses ou menos. A única exceção seria se isso não acontecesse: ou seja, a contagem de setores inválidos aumenta, mas fica estável por um longo período, como um ano ou mais. Por esse motivo, normalmente é necessária uma ferramenta de diagramação / registro no diário para o SMART.

De acordo com o documento do Google Labs, Failure Trends in a Large Disk Drive Population, “após o primeiro erro de verificação [qualquer tipo de erro de setor incorreto, causado por instabilidade de leitura ou danos à mídia], os drives têm 39 vezes mais probabilidade de falhar dentro de 60 dias do que os drives sem esses erros. Os primeiros erros nas realocações, realocações off-line e contagens probatórias também estão fortemente correlacionados a probabilidades de falha mais altas. Apesar dessas fortes correlações, constatamos que os modelos de previsão de falha baseados apenas nos parâmetros SMART são limitados em sua precisão de previsão, uma vez que uma grande fração de nossos drives com falhas não demonstrou nenhum sinal de erro SMART.”

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

Para ver um script que ajuda no monitoramento da saúde do HD e outros aspectos importantes de hardware um ou mais computadores, veja o post Monitorar status de computadores.

Configurando o smartd – verificação rotineira automática

Em vez de repetir a seção anterior diariamente, é possível configurar o smartd para fazer tudo automaticamente. Ele fica responsável por executar o teste conforme agendamento próprio e salvar os resultados no log do sistema, que você pode acompanhar usando o comando “cat /var/log/syslog | grep smartd” ou “smartctl -l selftest /dev/”.

Caso o computador tenha o arquivo “/etc/default/smartmontools”, descomente a linha contendo “start_smartd=yes”. O padrão do serviço é monitorar todos os HDs disponíveis, mas isso pode ser configurado no arquivo “/etc/smartd.conf”. Um exemplo de configuração desse arquivo:

1) Comentar a única linha descomentada por padrão, que começa com “DEVICESCAN”

2) Adicione a seguinte linha, cujos parâmetros podem ser opcionais em alguns casos:

/dev/sda -a -d sat -o on -S on -s (S/../.././02|L/../../6/03) -m root -M exec /usr/share/smartmontools/smartd-runner

Substitua “/dev/sda” pelo dispositivo que deseja monitorar (ou use DEVICESCAN para realizar o monitoramento em todos os dispositivos do computador). O parâmetro “-a” habilita algumas opções comumente utilizadas, “-d sat” força identificar o dispositivo como SATA (só usar no caso de não reconhecer), “-m root” manda e-mail além de gravar as saídas no log de sistema e “-M exec /usr/share/smartmontools/smartd-runner” é usado em distribuições Debian e Ubuntu.

As opções de agendamento são feitas através do parâmetro “-s”. Os campos são: tipo de teste (S ou L), mês (dois dígitos ou dois pontos para todos os meses), dia do mês (no mesmo esquema), dia da semana (onde 1 é segunda-feira e ponto é para todos os dias da semana) e hora de início (dois dígitos, indicando que começa em algum horário entre 1 e 2 da manhã). Para mais de um scan, separar por pipe cada grupo. No exemplo, estão programados um teste curto para ser executado diariamente às 2:00 da manhã e um teste longo no sábado às 3:00 da manhã.

Depois de alterar esse arquivo é preciso reiniciar o serviço através do seguinte comando “sudo /etc/init.d/smartmontools restart”. Mais informações em Monitoring Hard Drive Health on Linux with smartmontools e Monitorando a saúde do HD com o SMART, além do comando “man smartd.conf”.

Disco com erros de leitura

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

HDs em RAID

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 (instalado através do comando “apt-get install lsscsi” – veja mais no post Use smartctl To Check Disk Behind Adaptec RAID Controllers. 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:

6 comments

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.