dd copia mais dados do que existe em .img?

2

Estou tentando enviar um arquivo .img para o meu micro sd (8 GB). A rom (.img) tem 2,66 GB, mas na minha saída de DD (live) ela diz que transferiu 9 GB . Eu não entendo como está transformando uma imagem de 2 GB em 9 GB. Estou executando o OSX Lion e usando uma leitura de cartão da Belkin. O leitor de cartões não é o problema, eu usei utilitário de disco com ele sem nenhum problema. Eu acho que o problema é dd ou meu cartão (espero que não seja meu cartão :().

EDIT: Aqui está o comando que eu uso para copiar o arquivo

dd if=honey.img of=/dev/disk1 bs=1m

Este é o código que eu uso para verificar o status:

killall -INFO dd
    
por Sirens 29.04.2012 / 03:58

2 respostas

2

O comportamento que você descreve e a natureza do arquivo me faz suspeitar que este é um arquivo esparso . Arquivos esparsos são uma técnica de compactação primitiva, na qual grandes seqüências de bytes nulos em um arquivo não são armazenadas no disco. Aqui está um exemplo em que eu crio um arquivo esparso:

$ echo a | dd seek=999999999 >sparse
0+1 records in
0+1 records out
2 bytes (2 B) copied, 6.614e-05 s, 30.2 kB/s
$ ls -l a
-rw-r--r-- 1 gilles gilles 511999999490 Apr 30 00:03 sparse
$ du sparse
16      sparse

O arquivo sparse contém 511999999490 bytes (999999999 blocos de 512 bytes, todos zero, mais os dois bytes a seguidos por uma nova linha). No entanto, o espaço total em disco usado pelo arquivo é de 16kB (4kB para o bloco final e 3 outros blocos contendo apenas metadados relacionados à localização dos outros blocos - todos ausentes).

Se honey.img for uma imagem de disco que foi criada com cuidado o suficiente, pode ser esparso onde o disco tenha espaço não utilizado.

Quando você lê um arquivo, não há nada para marcá-lo como escasso. Portanto, se honey.img for uma imagem de disco grande, dd pode estar lendo gigabyte com gigabyte contendo apenas bytes nulos.

A execução de ls -l e du no arquivo (ou, no OSX, ls -ls ) mostraria o número de bytes e o número de blocos usados para armazenamento. Se os bytes não couberem no número de blocos, o arquivo é esparso. Enquanto escrevo, você não publicou dados legíveis que poderiam confirmar ou anular isso.

A única ferramenta que conheço no OSX que pode copiar arquivos esparsos com eficiência é rsync . No entanto, o que você está fazendo aqui não é copiar um arquivo de um sistema de arquivos para outro, mas copiar um fluxo de bytes (que vem de um arquivo) para um disco. Você só pode fazer isso se os dados realmente couberem no disco de destino.

    
por 30.04.2012 / 02:12
0

Eu me deparei com um problema muito semelhante tentando transferir um binary.img ao vivo do Debian para uma unidade flash USB de 2GB. O tamanho da imagem foi listado como 1,6 GB. O comentário de Matt acima sobre o uso do stat foi muito útil e depois de calcular o tamanho do bloco em 4096 vezes o número de blocos (3.109.040), ele coloca o tamanho em 12.734.627.840 que é quase 8 vezes o tamanho de 1,6GB listado. Notei que no comando dd eu estava usando o bs = 1M também, então eu tentei novamente com o bs = 4096 como listado no comando stat, e ele copiou o arquivo como originalmente esperado em 1.6GB. Então, minha impressão é que, se você copiar blocos maiores do que o tamanho do bloco, ele copia apenas bloco por bloco. Mas se você copiar no tamanho do bloco (e possivelmente menor, embora não testado) o dd avalia o que está dentro do bloco e apara o lixo supérfluo. Obrigado pela dica Matt.

    
por 22.06.2013 / 23:23

Tags