Como faço o meu disco inesperado pendente setores ilegíveis

Um setor irracional pendente é aquele que retornou um erro de leitura e que a unidade marcou para remear a primeira oportunidade possível. No entanto, não pode fazer o remapeamento até que uma das duas coisas acontece:

1. O setor é reler com sucesso
2. O setor é reescrito

Até lá, o setor permanece pendente. Então você tem duas maneiras correspondentes de lidar com isso:

1. Continue tentando reler o setor até você ter sucesso
2. Substituir esse setor com novos dados

Obviamente, (1) é não destrutivo, então você provavelmente deve tentar primeiro, embora tenha em mente que, se a unidade estiver começando a falhar de uma maneira séria, a leitura contínua de uma área ruim é provável que ele falhe muito mais rapidamente . Se você tiver muitos setores pendentes e outros erros, e se preocupa com os dados na unidade, recomendo a tirá-lo do serviço e usando a excelente ferramenta Ddescue para recuperar o máximo de dados possível. Em seguida, descarte a unidade.

Se o setor em questão contiver dados, você não se importa, ou pode restaurar de um backup, então sobrescrever é provavelmente a solução mais rápida e mais simples. Você pode ver as contagens realocadas e pendentes para a unidade para garantir que o setor tenha cuidado.

Como você descobre o que o setor corresponde ao sistema de arquivos? Eu encontrei um artigo excelente sobre o site smartMONTOOLS , aqui , embora seja bastante técnico e é específico para ext2/3/4 e sistemas de arquivos reiser.

Uma abordagem mais simples, que eu usei em uma das minhas unidades (MAC), é usar find / -xdev -type f -print0 | xargs -0 ... para ler todos os arquivos no sistema. Anote a conta pendente antes de executar isso. Se o setor estiver dentro de um arquivo, você receberá uma mensagem de erro na ferramenta usada para ler os arquivos (por exemplo, MD5SUM) mostrando o caminho para ele. Você pode, em seguida, concentrar suas atenções em reler apenas este arquivo até que ele seja com êxito. Muitas vezes isso resolverá o problema, se for um arquivo usado com pouca freqüência que só precisava ser reler algumas vezes. Se o erro desaparecer, ou você não encontrar algum erro ao ler todos os arquivos, verifique a contagem pendente para ver se ela diminuiu. Se tiver, o problema foi resolvido lendo.

Se o arquivo não puder ser lido com êxito após várias tentativas (por exemplo, 20), você precisará sobrescrever o arquivo ou o bloco dentro do arquivo, para permitir que a unidade realoque o setor. Você pode usar o DDRCUE no arquivo (em vez da partição) para sobrescrever apenas o setor, copiando para um arquivo temporário e, em seguida, copiando de volta novamente. Note que apenas remover o arquivo neste momento é uma má ideia, porque o setor ruim irá para a lista livre, onde será mais difícil encontrar. Completamente sobrescrito também é ruim, porque novamente os setores entrarão na lista livre. Você precisa reescrever os blocos existentes. O notrunc opção de dd é uma maneira de fazer isso.

Se você não encontrar erros, e a contagem pendente não diminuiu, o setor deve estar no freelist ou em parte da infraestrutura do sistema de arquivos (por exemplo, uma tabela de inode). Você pode tentar preencher todo o espaço livre com cat /dev/zero >tempfile e, em seguida, verifique a contagem pendente. Se descer, o problema estava na lista livre e agora foi embora.

Se o setor estiver na infraestrutura, você terá um problema mais sério, e provavelmente encontrará erros apenas andando na árvore de diretórios. Nessa situação, acho que a única solução sensata é reformatar a unidade, opcionalmente usando o DDRCUE para recuperar dados, se necessário.

Mantenha um olho muito próximo na unidade. Realocation do setor é muito bom Canário na mina de carvão , potencialmente dando-lhe aviso antecipado de uma unidade que está falhando. Ao receber uma ação antecipada, você pode impedir um deslizamento de terra catastrófico e muito doloroso. Não estou sugerindo que algumas realocações do setor são uma indicação de que você deve descartar a unidade. Todas as unidades modernas precisam fazer alguma realocação. No entanto, se a unidade não for muito antiga (<1 ano) ou você está recebendo novas realocações frequentes (> 1/mês), eu recomendo que você substitua o mais cedo possível.

Eu não tenho evidências empíricas para provar isso, mas minha experiência sugere que os problemas de disco podem ser reduzidos lendo o disco inteiro de vez em quando, seja por um dd do disco bruto ou lendo cada arquivo usando find. Quase todos os problemas de disco que experimentei nos últimos vários anos surgiram primeiro em arquivos raramente usados, ou em máquinas que não são muito usadas. Isso também faz sentido, também, em que, se um setor está sendo relido com frequência, a unidade tem a chance de realocá-lo quando primeiro detecta um pequeno problema com esse setor, em vez de esperar até que o setor seja completamente ilegível. A unidade é impotente para fazer qualquer coisa com um setor, a menos que o host acesse de alguma forma, seja lendo ou escrevendo ou conduzindo um dos testes SMART.

Eu gostaria de experimentar a ideia de um trabalho de cron noturno ou semanal que lê o disco inteiro. Atualmente estou usando um "Raid do homem pobre" no qual eu tenho um segundo disco rígido na máquina e recupero o disco principal a cada noite. De certa forma, isso é realmente melhor que o espelhamento de Raid, porque se eu goof e excluir um arquivo por engano, posso obter a versão de ontem imediatamente no disco de backup. Por outro lado, acredito que um controlador RAID de hardware faz um monte de bom trabalho em segundo plano para monitorar, relatar e corrigir problemas em disco à medida que surgem. Meu script de backup atual usa rsync para evitar copiar dados que não foram alterados, mas em vista da necessidade de reler todos os setores, talvez seja melhor copiar tudo, ou para ter um script separado que lê todo o script disco bruto toda semana.