Meu sistema Linux começou a gerar erros SMART no syslog. Eu o localizei e acredito que o problema seja um único bloco no disco. Como faço para que o disco realoque facilmente esse bloco? Gostaria de saber qual arquivo foi destruído no processo. (Estou ciente de que, se um bloco falhar em um disco, outros provavelmente o seguirão; tenho um bom backup contínuo e só quero tentar manter esse disco funcionando.)
Pesquisar na web leva ao bloco ruim COMO FAZER, que descreve um processo manual em um disco desmontado. Parece complicado e sujeito a erros. Existe uma ferramenta para automatizar esse processo no Linux? Minha única outra opção éa ferramenta de diagnóstico do fabricante, mas presumo que isso destruirá o bloco defeituoso sem qualquer relatório sobre o que foi destruído. Na pior das hipóteses, podem ser metadados do sistema de arquivos.
O disco em questão é a partição primária do sistema. Usando ext3fs e LVM. Aqui está o log de erros do syslog e o bit relevante do smartctl.
smartd[5226]: Device: /dev/hda, 1 Currently unreadable (pending) sectors
Error 1 occurred at disk power-on lifetime: 17449 hours (727 days + 1 hours)
... Error: UNC at LBA = 0x00d39eee = 13868782
Há um despejo smartctl completono pastebin.
Responder1
Você poderia tentar hdparm --write-sector <LBA> /dev/ice.
Não conheço outra maneira de fazer isso - você precisa converter manualmente o LBA em blocos do sistema de arquivos (como você já descobriu)
Responder2
Eu costumava escrever firmware de disco para WD e uma vez escrevi o firmware que reatribuía blocos defeituosos.
Primeiro, a maioria dos blocos defeituosos são detectados em leituras, não em gravações. As gravações são feitas às cegas, o que significa que os dados são gravados sem serem verificados. Assim, em uma gravação, se a mídia estiver ruim, você não saberá até que o host faça uma leitura nesse setor. Há uma pequena parte do setor (o cabeçalho do setor) que é lida nas gravações para localizar o setor correto, de forma que se houver um erro na leitura do cabeçalho do setor, o drive irá reatribuir o setor e gravá-lo com os dados recebidos do comando de gravação. Mas a grande maioria dos blocos defeituosos são detectados nas leituras, e só porque uma gravação foi bem-sucedida em um setor não significa que a mídia esteja boa ou que o setor tenha sido reatribuído.
Agora, sobre a reatribuição de blocos incorretos (também chamada de realocação). Sim, normalmente a unidade tentará reatribuir um setor se o erro for grave o suficiente (ou seja, a falha do ECC for suficientemente grave), mas a unidade ainda poderá recuperar os dados após a correção do ECC. Geralmente isso é feito automaticamente. A única exceção é que o host poderia ter dito anteriormente à unidade para não fazer realocações automáticas, mas isso raramente é feito.
Então, o que acontece se a unidade fizer uma leitura e não conseguir recuperar os dados? Nada. O erro é relatado ao host, mas nenhuma reatribuição é feita. O problema é que a unidade poderia reatribuir o setor, mas não tem a menor ideia de quais dados gravar no setor recém-reatribuído. Se ele apenas escrevesse um monte de zeros, digamos, e então o setor fosse lido novamente, ele retornaria todos os zeros sem qualquer indicação de que os dados não eram válidos. Isto é essencialmente a mesma coisa que corrupção de dados. A unidade não pode contar com o host para monitorar os erros por vários motivos (por exemplo, e se a unidade for movida para um novo host?), portanto, o melhor curso de ação é não fazer nada quando os dados puderem. não ser recuperado.
As unidades modernas, entretanto, salvarão a localização do setor defeituoso quando ele não puder ser realocado. O número de setores defeituosos aguardando realocação pode ser encontrado nos dados SMART. O que acontece é que se for feita uma gravação em um dos setores defeituosos aguardando a realocação, a realocação será feita porque a unidade agora possui dados válidos para gravar após a realocação. Assim, quando as pessoas dizem que escrever para um setor defeituoso irá realocá-lo, isso é apenas metade da história. A unidade deve ser lida primeiro para que possa descobrir todos os setores defeituosos que não podem ser realocados automaticamente. Assim, você pode gravar uma unidade inteira e os dados SMART dirão que não há setores defeituosos aguardando realocação, mas você não necessariamente limpou todos os setores defeituosos da unidade. Portanto, se você realmente deseja limpar todos os setores defeituosos de uma unidade, a melhor coisa é primeiro ler a unidade inteira e depois gravar a unidade inteira (é claro, isso destruirá todos os dados anteriores na unidade).
Existem outras maneiras de lidar com blocos defeituosos que não podem ser realocados. Se a unidade fizer parte de uma configuração RAID redundante (ou seja, qualquer coisa que não seja RAID 0), o software RAID deverá recuperar automaticamente os dados de um setor defeituoso das outras unidades e gravá-los no setor realocado. Os discos SCSI possuem um comando explícito de reatribuição de blocos que o host pode usar para forçar a reatribuição mesmo quando não há dados válidos para gravar no bloco, mas seu uso é de nível bastante baixo.
Responder3
Acho que tudo que você precisa fazer é:
e2fsck -c /dev/hda1
assumindo que /dev/hda1 é a partição (desmontada). Ou:
e2fsck -c -c /dev/hda1
para fazer um teste de leitura e gravação não destrutivo (mais lento). Ainda terá que ser desmontado. Porém, não acho que isso fornecerá detalhes sobre quaisquer dados perdidos.
Responder4
Se você tem backups e sabe que isso é um erro lógico e não físico, a melhor maneira de fazer isso seria zerar o disco.
Eu usaria MHDD, é bastante fácil de usar e contanto que você se lembre de configurar seu HDD no BIOS para emulação IDE e depois voltar para AHCI quando seu trabalho estiver concluído, você não terá nada com que se preocupar.
Depois de inicializar no MHDD, escolha o tipo de unidade no comando ERASE e confirme sua escolha.
Arranja um café, isso pode demorar um pouco.
Depois que o Drive for zerado, execute scan(f4) com Remap definido como ON (o padrão é desligado). Se ainda houver problemas com a unidade (isso significaria que há um dano físico no prato e a unidade está em uma descida constante), esta opção irá "consertá-los" mapeando a área danificada para partes saudáveis da unidade.
Se não houver erros UNC, parabéns, você e sua unidade ainda poderão ser amigos nos próximos anos.