Você pode tentar hdparm --write-sector <LBA> /dev/ice .
Eu não conheço nenhuma outra maneira de fazer isso - você precisa converter manualmente o LBA em blocos do sistema de arquivos (como você já encontrou)
Meu sistema Linux começou a gerar erros SMART no syslog. Eu rastreei e acredito que o problema é um único bloco no disco. Como faço para obter facilmente o disco para realocar esse bloco? Eu gostaria de saber qual arquivo foi destruído no processo. (Estou ciente de que, se um bloco falhar em um disco, é provável que outros o sigam; tenho um bom backup em andamento e apenas quero tentar manter esse disco funcionando.)
A pesquisa na Web leva ao o HOWTO de Blocos inválidos , que descreve um processo manual em um disco desmontado. Parece complicado e propenso a erros. Existe uma ferramenta para automatizar esse processo no Linux? Minha única outra opção é a ferramenta de diagnóstico do fabricante , mas eu suponha que isso vai destruir o bloco ruim sem relatar o que foi destruído. Na pior das hipóteses, pode ser um metadado do sistema de arquivos.
O disco em questão é a partição do sistema principal. 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 dump completo de smartctl em pastebin .
Eu costumava escrever firmware de disco para a WD, e uma vez eu escrevi o firmware que reatribui os blocos ruins.
Primeiro, a maioria dos blocos defeituosos é detectada em leituras, não em gravações. As gravações são feitas às cegas, ou seja, 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 para esse setor. Há uma pequena parte do setor (o cabeçalho do setor) que é lido nas gravações para localizar o setor correto, de modo que, se houver um erro na leitura do cabeçalho do setor, a unidade redesignará o setor e o escreverá com os dados recebidos. do comando de gravação. Mas a grande maioria dos blocos defeituosos é detectada nas leituras, e só porque uma gravação é bem-sucedida para um setor não significa que a mídia seja boa ou que o setor tenha sido redesignado.
Agora sobre reatribuição de bloco ruim (também chamada de realocação). Sim, normalmente a unidade tentará reatribuir um setor se o erro for ruim o suficiente (ou seja, a falha do ECC é ruim o suficiente), mas o inversor ainda pode recuperar os dados após a correção do ECC. Geralmente isso é feito automaticamente. A única exceção é que o host poderia ter informado anteriormente à unidade para não realizar realocações automáticas, mas isso raramente é feito.
Então, o que acontece se a unidade fizer uma leitura e não puder recuperar os dados? Nada. O erro é relatado ao host, mas nenhuma reconsignação é feita. O problema é que a unidade poderia reatribuir o setor, mas não tem a menor idéia de quais dados escrever no setor recém-redesignado. Se ele escrevesse um monte de zeros, digamos, e o setor fosse lido novamente, ele retornaria todos os zeros sem qualquer indicação de que os dados não eram válidos. Isso é essencialmente a mesma coisa que corrupção de dados. A unidade não pode contar com o host mantendo o controle de erros por vários motivos (por exemplo, e se a unidade foi movida para um novo host?), Portanto, o melhor curso de ação é não fazer nada quando os dados puderem ' t ser recuperado.
As unidades modernas, no entanto, salvarão a localização do setor defeituoso quando ele não puder ser realocado. O número de setores defeituosos que aguardam realocação pode ser encontrado nos dados SMART. O que acontece é que se uma gravação é feita para um dos setores defeituosos que aguardam realocação, a realocação é feita porque a unidade agora tem dados válidos para gravar após a realocação. Assim, quando as pessoas dizem que escrever para um setor ruim irá realocá-lo, isso é apenas metade da história. A unidade deve ser lida primeiro para que a unidade possa descobrir todos os setores defeituosos que não podem ser realocados automaticamente. Assim, você pode escrever uma unidade inteira, e os dados SMART dirão que não há setores defeituosos aguardando realocação, mas você não necessariamente limpou a unidade de todos os setores defeituosos. Portanto, se você realmente deseja limpar uma unidade de todos os setores defeituosos, a melhor coisa é ler a unidade inteira primeiro, seguida da gravação da unidade inteira (isso destruirá todos os dados anteriores da unidade).
Existem outras maneiras de lidar com blocos ruins que não podem ser realocados. Se a unidade fizer parte de uma configuração RAID redundante (ou seja, qualquer coisa, exceto 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 têm 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 muito baixo.
Acho que tudo o 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 / gravação não-destrutivo (mais lento). Ainda terá que ser desmontado. Eu não acho que isso vai lhe dar detalhes sobre quaisquer dados perdidos, no entanto.
Michael está correto e, na maioria dos casos, eu diria que basta substituir a unidade por eles serem baratos. No entanto, se você não tiver backups e não conseguir obter dados importantes da unidade, ou apenas tentar reparar a unidade, talvez seja melhor tentar usar spinrite , no nível mais alto.
Eu tinha uma unidade de laptop que começou a fazer alguns ruídos há alguns anos. Badblocks mostraram que a unidade tinha 118 ou mais blocos ruins visíveis para o usuário final. Como eu já tinha uma cópia do SpinRite, decidi experimentá-la antes de comprar uma nova unidade. Depois de executar o spinrite nos badblocks da unidade, mostrou 0 blocos defeituosos e os ruídos pararam. A unidade estava funcionando há mais de dois anos desde então.
Se você tem backups e sabe que isso é um erro lógico e não físico, então a melhor maneira de fazer isso seria zerar o disco.
Eu usaria MHDD é bastante fácil de usar e desde que você lembre de configurar seu HDD em Bios para emulação IDE e depois voltar para AHCI quando seu trabalho estiver pronto, você não terá com o que se preocupar.
Depois de inicializar no MHDD, escolha o tipo de unidade no comando ERASE e confirme sua escolha.
Pegue-se coffie isso pode demorar um pouco.
Depois que o Drive for zerado, execute a varredura (f4) com Remap configurado como ON (o padrão é desativado). Se ainda houver problemas com o inversor (isso significaria que há um dano físico no prato e o inversor está em um declive acentuado), essa opção os "Fixará" mapeando a área danificada para partes saudáveis do disco.
Se não houver erros de UNC, parabéns pelo fato de você e sua unidade ainda poderem ser amigos nos próximos anos.
Se o disco está indo mal, substitua-o. Não vale a pena o risco de desmoronar mais.
Tags hard-drive lvm smart linux smartctl