Quão grande é a img que o dd cria?

Question

Esta é a primeira vez que uso o comando dd. Eu executo:

dd if=/dev/sdb2 of=/mnt/sdc1/Hdd1.img bs=512 conv=noerror,sync

Onde o sdb é o disco rígido destruído (tamanho: 500 GB). Eu copiando a partição sdb2 em uma imagem. Eu fiz isso 6 (!!) dias. o tamanho img é de cerca de 640 GB e continua a contar (ou seja: ainda não terminou ...). 6 dias ele está imprimindo os detalhes dos dados copiados (cujo byte é copiado para onde) e não está parando.

Isso é normal? como é possível que o tamanho img seja maior que todo o tamanho do disco rígido destruído? e quando se supõe terminar?

    

Answer 1

Ao fazer a cópia de 512 bytes por vez, você está fazendo muitas e muitas leituras e gravações. Cerca de um trilhão, na verdade, se você fizer as contas. Você também solicitou a sincronização [EDIT: isso não é oflag=sync , então a próxima instrução é inválida], o que significa esperar que cada gravação realmente saia no disco antes que a gravação possa retornar. Digamos que seu disco seja bem rápido, então cada gravação demora 2ms.

500gb / 512 bytes * 2ms = 22,6 dias.

Uau, trilhões bilhões de milissegundos somaram rápido, não foi?

[EDIT: enquanto isso foi certamente um pouco divertido de matemática, não é preciso, já que oflag=sync não foi usado. Os atrasos são mais prováveis devido à leitura repetida de setores defeituosos e aos tempos limite associados. A abordagem dd_rescue abaixo deve ajudar bastante. Usar o dd simples com um tamanho de bloco maior pode ajudar, mas não tanto, já que ele não pode adaptar seu tamanho de leitura e não pula o dano massivo.]

Se você usar um tamanho de bloco maior e / ou ignorar a sincronização, ele será MUITO mais rápido:

# dd if=/dev/sdb2 of=/sdb2-image.img bs=1024k

Se você estiver preocupado com erros de leitura na leitura da imagem sdb2, use dd_rescue com a opção -A para gravar um bloco de zeros em vez de ignorar essa gravação. Ignorar blocos com erros pode levar a problemas quando determinadas estruturas do sistema de arquivos aparecem em diferentes deslocamentos desde o início do que eram originalmente. É melhor ter apenas alguns zeros inesperados. Por exemplo:

# dd_rescue -A /dev/sdb2 /sdb2-image.img

Isso começará a ler grandes blocos de dados de uma só vez e só os reduzirá ao começar a gerar erros.

EDIT: para responder diretamente à pergunta, conforme sugerido por Micheal Johnson, ao usar conv=noerror,sync em dd ou -A on dd_rescue , sua imagem terá o mesmo tamanho exato de sua fonte. Isso ocorre porque toda leitura gerará uma gravação de tamanho idêntico. Algumas versões do dd podem continuar a funcionar muito tempo depois do fim do dispositivo, uma vez que ignoram o "erro" no fim do ficheiro por pedido do conv=noerror . Eu não acho que o Linux faça isso, mas é algo para se observar se a sua imagem parece estar ficando maior do que a fonte.

    

Answer 2

O tamanho da imagem é o mesmo que o tamanho da partição da qual você está criando a imagem. Você não disse quão grande é a sua partição, mas se, digamos, metade da capacidade total do disco rígido, seu tamanho declarado não é razoável, dependendo do tamanho do disco rígido. O importante é que a partição em que você está salvando a imagem tenha pelo menos o mesmo espaço livre que o tamanho da partição que você está visualizando - se não, a operação falhará com um erro "sem espaço deixado no dispositivo". Além disso, se sdc for "destruído", salvar a imagem em sdc1 (como sugerido pelo caminho do arquivo de imagem) provavelmente é uma má idéia - talvez você possa esclarecer o que entende por "destruído"?

De qualquer forma, a resposta de Steve Bonds explica por que está demorando tanto, mas essa não foi a pergunta que você fez.