Cuidado: a solução descrita neste artigo não é profissional; pode ter sido criada com base em um mal-entendido da estrutura e dos princípios de operação dos discos rígidos. Repetir as etapas acima pode danificar o equipamento.
Recentemente, deparei com um artigo sobre o uso de HDDs antigos com blocos ruins e pensei que minha experiência também poderia ser interessante para alguém.
Uma vez, os conhecidos me pediram para ajudar a lidar com um laptop no qual não podiam reinstalar o Windows. A julgar pela aparência, o laptop teve uma vida difícil: rachaduras no gabinete, cantos amassados, racks quebrados. Está claro que o problema é o dano ao disco rígido como resultado de numerosos cursos, o que também foi confirmado pela smart: mais de 200 operações de sensor G, 500 contagens de setores realocados e ainda há pendente atual. Bem, pessoal, é claro, eu instalei o SSD e copiei as informações do parafuso na imagem com o comando:
dd if=/dev/sdb of=/media/hddimages/ht320.img bs=409600 conv=noerror,notrunc,sync
Os parâmetros "conv = noerror, notrunc, sync" são necessários para que, em caso de erros na leitura de certos setores, zeros sejam gravados nesses endereços no arquivo de saída e os dados sejam gravados em seu lugar sem viés.
Ocorre que ao ler em blocos grandes (400kb), o disco não lê o bloco inteiro e os menores não lêem apenas 1 setor. Os setores aqui são de 4kb, portanto, após a primeira passagem do dd, se houver erros de leitura, tento ler essas seções novamente em blocos de 4kb:
n=<>;dd if=/dev/sdb of=/media/hddimages/ht320.img bs=4096 conv=noerror,notrunc,sync skip=$n seek=$n count=100
Os parâmetros de ignorar e procurar são necessários para que a leitura e a gravação comecem com o mesmo recuo desde o início do disco. O recuo em si é obtido da saída da primeira execução de dd, apenas para corresponder ao tamanho do bloco, multiplique o número por 100.
Às vezes, ao acessar setores defeituosos, os discos congelam por muito tempo, tanto que apenas a reconexão com a energia ajuda e, há cerca de 5 anos, foi criado um complexo de hardware / software (com um microcontrolador) para automatizar a leitura de hards ruins com a reconexão automática de energia uma longa falta de resposta. Foi interessante e permitido, conectando o disco rígido e inserindo o comando, após 10 dias para obter a imagem mais completa. Mas o herói experimental do artigo não ficou firme, então não havia necessidade de obter a muleta pesada descrita.
Então, o disco foi considerado, montei todas as seções da imagem através de losetup com deslocamentos do início das partições do fdisk, multiplicado pelo tamanho do bloco lógico em mbr - 512 bytes, copio todos os dados para as pessoas em um novo SSD. Se o disco não estivesse montado ou muitos arquivos não pudessem ser lidos, eu abriria a imagem com o R-Studio e a restauraria através dele, mas a partir da própria imagem.
Mas o duro, apesar de derrotado, é uma pena deitar fora, então decidi reanimá-lo. Teoricamente, o controlador de disco marca os setores como danificados e reatribui os setores de backup aos seus endereços no caso de repetidas tentativas malsucedidas de gravar ou de erros de leitura irrecuperáveis (usando ECC).
Primeiro, tento limpar o disco (dd se = / dev / zero ...) e ler depois: a velocidade também é instável, o disco congela e, às vezes, ocorre um erro de entrada / saída, mas no smart o número de relocks e pendings está aumentando. Depois de vários ciclos, o smart não mudou muito, os pendentes não foram realocados e os travamentos ocorrem com erros todas as vezes nos mesmos locais ou nas proximidades. Eu tento remapear manualmente com o comando "hdparm --make-bad-sector", mas isso não funciona nesse modelo e chego à conclusão de que apenas a leitura e a leitura e a escrita não serão capazes de mostrar todas as áreas problemáticas. De fato, se um bit danificado, independentemente do que eles tentaram escrever, é mais provável que seja lido como "1", então ao escrever para "1", a leitura subsequente ocorrerá sem erros, mas ao escrever um padrão diferente, poderá existem inconsistências suficientes para que o ECC falhe e ocorra um erro de leitura irreparável. Após vários casos, o setor recebeu o status de "Ruim". A propósito, o valor registrado pode ser tão sobreposto à distribuição de bits danificados que um valor incorreto de leitura satisfará o ECC. Portanto, para maximizar a identificação de todos os setores defeituosos, é necessário gerar um padrão relativamente aleatório, gravá-lo no disco, ler e comparar o valor. Existem também setores instáveis, que alteram seus valores gradualmente ao longo do tempo ou após o processamento de seus vizinhos.
Dado todo o exposto, decidi implementar a seguinte estratégia em um script bash:
- nós geramos um padrão aleatório e consideramos a soma de verificação para ele;
- nós lemos espertos;
- escreva um disco em zeros;
- leia o disco;
- nós escrevemos um disco em um padrão aleatório lendo o bloco recém-gravado e comparando sua soma de verificação;
- lemos o disco após a gravação completa, verificando as somas de verificação de cada bloco;
- nós lemos espertos;
- autoteste;
- ir para 1.
Continuamos assim até que os setores com leitura incorreta e erros de IO parem de acontecer ou até que o parafuso esteja completamente coberto. A propósito, como o autoteste funciona para esse modelo de disco, não consigo imaginar; Não sei quanto tempo difere de short'a (embora provavelmente trabalhe com toda a superfície e curto - com foco nas estatísticas coletadas anteriormente, como na formatação: completa e rápida). Espero que isso incentive o parafuso a levar em conta a experiência recente e remapear setores defeituosos.
Quando terminei de escrever o script bash, executei e verifiquei os resultados no dia seguinte - vi que a verificação é muito lenta, enquanto a carga do processador não atinge 60% em nenhum núcleo. Isso me fez brincar com o tamanho do bloco, testar diferentes algoritmos de hash para somas de verificação, experimentar a verificação direta de diferenças e não comparar somas de verificação, mas não consegui atingir velocidades de processamento acima de 12 megabytes por segundo. Como resultado, parei de comparar blocos de 400kb com diff e calculo as somas de verificação apenas se houver uma incompatibilidade apenas para a análise subsequente do log.
Como os logs mostraram após a execução repetida do script, todos os setores defeituosos estavam nos primeiros 13 GB do disco, houve vários "focos" de derrota (provavelmente, quando a cabeça bateu, a superfície foi arranhada e arranhada). Nas últimas 15 execuções, o disco não viu nenhum setor pendente, tudo já foi remapeado, mas em algum momento do 13º Gigabyte, um bloco ou blocos não muito distantes foram lidos incorretamente em endereços diferentes. Além disso, um bloco pode ser considerado incorreto por 2 ciclos seguidos, depois 2 vezes corretamente e novamente incorretamente. Então, pegar os últimos 10 setores ruins foi uma operação longa. Um total de 1268 setores foram remapeados! E no final, uma surpresa me aguardou: quando tudo já estava funcionando de maneira estável, após o próximo autoteste, o parâmetro Reallocated Sector Count tornou-se "0" e apenas o Reallocated Event Count e os registros dos últimos 5 erros (com endereço e hora de iniciar o trabalho) armazenado no diário.
Apesar da operação estável, decidi minimizar a interação com a área danificada para não ferir a cabeça sobre possíveis irregularidades em locais com superfície danificada das placas, e não queria confiar nos setores locais a longo prazo. Recuei um pouco com uma margem e criei uma partição começando com o 15º Gigabyte. E, como o tempo mostrou, o disco parece muito bom e está funcionando de maneira estável em um laptop portátil por 10 meses.
Embora seja impossível confiar totalmente no disco restaurado e a viabilidade econômica do empreendimento seja duvidosa, às vezes o resultado é apenas uma adição agradável ao bom caminho.