Suponha que haja um disco rígido /dev/sdae ambos:
/dev/sda1é uma única partição ext4 que ocupa todo o disco e está praticamente vazia de dados.dumpe2fs -b /dev/sda1gera a lista de badblocks, que neste caso gera um único número alto b representando um bloco defeituoso próximo ao final de/dev/sda; b felizmente não faz parte de nenhum arquivo.
Agora, uma partição swap precisa ser adicionada ao início de /dev/sda1, e gparted( v0.30.0-3ubuntu1 ) é usado para:
- Redimensione (encolher) sda1 , para que inicie vários gigabytes depois, mas termine no mesmo local.
- Adicione uma partição swap na lacuna deixada reduzindo sda1 .
Assim gpartedtermina o trabalho e corremos dumpe2fs -b /dev/sda1novamente. O que acontece? Será que...?
- Não produz nada, o que significa que o redimensionamento esqueceu o bloco defeituoso.
- Saída b inalterada.
- Saída b + o onde o é um deslocamento correspondente a onde o recém-encolhido
/dev/sda1agora começa.
NOTA: Para simplificar a questão, suponha que o disco rígido em questão não tenha firmware SMART . (Comentários sobre firmware estão fora do tópico.)
O GParted não leva em consideração nenhuma lista de badblocks ext2/3/4; Eu verifiquei isso criando um sistema de arquivos ext4 com um bloco defeituoso de força e, em seguida, movendo-o usando o GParted. A execução
dumpe2fs -bna partição movida mostra o bloco defeituoso no mesmo deslocamento.O resultado é 2, portanto, o bloco inválido ignorado pelo sistema de arquivos não corresponde mais ao bloco inválido real na mídia. Isso significa que o sistema de arquivos ignora um bloco que poderia usar com segurança e está sujeito a usar o bloco defeituoso que deve evitar.
Isso faz sentido, em algum nível. Quando o GParted (ou qualquer outra ferramenta) move uma partição, ele não usa uma ferramenta específica do sistema de arquivos, ele move o contêiner. Isso funciona em geral porque os dados do sistema de arquivos são relativos ao seu contêiner; geralmente as estruturas de dados do sistema de arquivos não precisam ser atualizadas como resultado de uma movimentação. No entanto, listas de blocos ruins descrevem recursos que não se movem com seu contêiner... Fazer o GParted lidar com isso seria bastante complexo: não apenas ele teria que atualizar a própria lista de blocos ruins, mas também teria que mover os dados para fora do caminho para que a nova posição do bloco defeituoso no sistema de arquivos movido não seja utilizada.
Os blocos defeituosos não seriam removidos, pois vi um clone de um disco ler blocos defeituosos quando gravados em um novo disco. Os próprios blocos ruins são marcados. Esses blocos defeituosos devem ser verificados novamente e marcados como limpos por uma ferramenta de fixação, por exemplo
fsck,ntfsfixou outra. Esses, no entanto, são badblocks fantasmas, não badblocks reais. Isso, no entanto, comprova a ideia de que eles devem ser fixados para serem removidos. O redimensionamento não deve limpar as marcas e um formato completo dessa partição deve criar novos marcadores de local para elas. Quanto a onde ele irá apontar após a operação, não me lembro. No entanto, isso pode ser testado, como disse agc.