Um setor ilegível pendente é aquele que retornou um erro de leitura e que a unidade marcou para remapear na primeira oportunidade possível. No entanto, ele não pode fazer o remapeamento até que uma das duas coisas aconteça:
- O setor é relido com sucesso
- O setor é reescrito
Até então, o setor permanece pendente. Então você tem duas maneiras correspondentes de lidar com isso:
- Continue tentando reler o setor até conseguir
- Substitua esse setor por novos dados
Obviamente, (1) é não destrutivo, portanto, você provavelmente deve experimentá-lo primeiro, embora tenha em mente que, se a unidade estiver começando a falhar de maneira séria, é provável que a leitura contínua de uma área ruim a faça falhar muito mais rapidamente . Se você possui muitos setores pendentes e outros erros e se preocupa com os dados na unidade, recomendo tirá-los de serviço e usar a excelente ferramenta ddrescue para recuperar o máximo de dados possível. Em seguida, descarte a unidade.
Se o setor em questão contiver dados com os quais você não se importa, ou puder restaurar a partir de um backup, substituí-lo é provavelmente a solução mais rápida e simples. Você pode visualizar as contagens realocadas e pendentes da unidade para garantir que o setor foi atendido.
Como você descobre a que setor corresponde o sistema de arquivos? Eu encontrei um excelente artigo sobre o smartmontools site, aqui , embora seja bastante técnico e é específico para ext2 / 3/4 e arquivo reiser sistemas.
Uma abordagem mais simples, que eu usei em uma das minhas próprias unidades (Mac), é usar find / -xdev -type f -print0 | xargs -0 ...para ler todos os arquivos no sistema. Anote a contagem pendente antes de executar isso. Se o setor estiver dentro de um arquivo, você receberá uma mensagem de erro da ferramenta usada para ler os arquivos (por exemplo, md5sum) mostrando o caminho para ele. Em seguida, você pode concentrar suas atenções na leitura apenas deste arquivo até que ele seja lido com êxito. Frequentemente, isso resolverá o problema, se for um arquivo usado com pouca frequência, que só precisa ser relido algumas vezes. Se o erro desaparecer ou você não encontrar nenhum erro ao ler todos os arquivos, verifique a contagem pendente para ver se ela diminuiu. Se tiver, o problema foi resolvido pela leitura.
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 ddrescue no arquivo (em vez da partição) para substituir apenas um setor, copiando para um arquivo temporário e copiando novamente. Observe que apenas remover o arquivo nesse momento é uma péssima idéia, porque o setor defeituoso entrará na lista gratuita, onde será mais difícil encontrá-lo. Substituir completamente também é ruim, porque novamente os setores entrarão na lista gratuita. Você precisa reescrever os blocos existentes. A notruncopção de ddé uma maneira de fazer isso.
Se você não encontrar erros e a contagem pendente não diminuir, o setor deverá estar no freelist ou em parte da infraestrutura do sistema de arquivos (por exemplo, uma tabela de inodes). Você pode tentar preencher todo o espaço livre cat /dev/zero >tempfilee verificar a contagem pendente. Se cair, o problema estava na lista gratuita e agora desapareceu.
Se o setor estiver na infraestrutura, você terá um problema mais sério e provavelmente encontrará erros apenas ao percorrer a árvore de diretórios. Nessa situação, acho que a única solução sensata é reformatar a unidade, opcionalmente usando o ddrescue para recuperar dados, se necessário.
Fique de olho na unidade. A realocação do setor é um canário muito bom na mina de carvão , potencialmente dando a você um aviso prévio de uma falha na unidade. Ao tomar medidas precoces, você pode evitar um deslizamento de terra catastrófico e muito doloroso. Não estou sugerindo que algumas realocações de setor sejam uma indicação de que você deve descartar a unidade. Todas as unidades modernas precisam realizar alguma realocação. No entanto, se a unidade não for muito antiga (<1 ano) ou você estiver recebendo novas realocações frequentes (> 1 / mês), recomendamos que você a substitua o mais rápido possível.
Não tenho evidências empíricas para provar isso, mas minha experiência sugere que os problemas no disco podem ser reduzidos lendo o disco inteiro de vez em quando, seja por um dddisco bruto ou lendo todos os arquivos usando find. Quase todos os problemas de disco que experimentei nos últimos anos surgiram primeiro em arquivos raramente usados ou em máquinas que não são muito usadas. Isso também faz sentido heuristicamente, pois, se um setor estiver sendo relido com freqüência, a unidade terá uma chance de realocá-lo quando detectar um problema menor com esse setor, em vez de esperar até que o setor fique completamente ilegível. A unidade é impotente para fazer qualquer coisa com um setor, a menos que o host a acesse de alguma forma, lendo ou gravando ou realizando um dos testes SMART.
Eu gostaria de experimentar a idéia de um trabalho cron noturno ou semanal que leia todo o disco. Atualmente, estou usando o "RAID do pobre homem" no qual tenho um segundo disco rígido na máquina e faço backup do disco principal todas as noites. De certa forma, isso é realmente melhor do que o espelhamento RAID, porque se eu excluir e excluir um arquivo por engano, posso obter a versão de ontem imediatamente do disco de backup. Por outro lado, acredito que um controlador RAID de hardware faz um bom trabalho em segundo plano para monitorar, relatar e corrigir problemas de disco à medida que surgem. Meu script de backup atual usa rsyncpara evitar a cópia de dados que não foram alterados, mas, considerando a necessidade de reler todos os setores, talvez seja melhor copiar tudo ou ter um script separado que leia todo o disco bruto toda semana.