Por que um clone de disco usando o dd ocupa mais espaço no destino do que a imagem de origem?

Question

Estou fazendo algum desenvolvimento para Android no Ubuntu 11.10. Eu estou construindo um conjunto de cartão SD e eMMC cartão de imagens Android usando um script Bash.

Devido às idiossincrasias do Android, tenho várias imagens do sistema de arquivos que precisam ser copiadas para o cartão de destino. Existem várias linhas no meu script para copiar as imagens que se parecem com isso:

image_dir=/some/directory
node=/dev/some/block/device
dd if=${image_dir}/data.img of=${node}; sync

Aqui é onde as coisas ficam estranhas. Depois de particionar o cartão e copiar data.img usando esse comando dd , há uma grande inconsistência entre o tamanho do data.img em minha máquina dev e a quantidade de espaço ocupado na partição do cartão SD de destino.

Por exemplo, o arquivo data.img no meu disco ocupa aproximadamente 128 megabytes de espaço, aproximadamente, mas ocupa quase 2,5 gigabytes na partição do cartão SD . Por razões óbvias, este é um problema sério.

Eu tentei modificar o número de blocos que dd lê e escreve, mas isso não parece alterar a quantidade de espaço necessária. Eu fiz um pouco de googling, mas não consigo encontrar nenhuma referência a problemas como este.

O que posso fazer para corrigir esse problema para que a imagem não ocupe muito espaço? Pode haver algo errado com o arquivo data.img ? Estou usando dd errado?

Eu tenho arrancado meu cabelo por uma semana, me ajude StackExchange, você é minha única esperança.

EDIT: Pergunta esclarecida acima: Não é que o sistema de arquivos ocupe muito espaço na partição, é que a partição é preenchida quase completamente com dados após executar dd , apesar da imagem do sistema de arquivos sendo substancialmente menor que a dita partição.

    

Answer 1

A primeira coisa que vem à mente é "arquivos furos ". Se um programa abrir um arquivo e usar a chamada de sistema lseek() para definir o deslocamento do arquivo como maior que um file-system-block e, em seguida, gravar alguns bytes, o código do sistema de arquivos alocará apenas um bloco para os dados gravados. O primeiro bloco do sistema de arquivos não é alocado. Se outro programa abrir o arquivo e ler alguns bytes nesse bloco de sistema de arquivos, ele obtém bytes de valor zero.

Um programa pode pular um bloco em qualquer lugar no arquivo, não apenas no começo. Assim, "arquivos com buracos".

Ter uma ampliação de backup em tamanho não é incomum para o Linux / Unix, mas o culpado geralmente é algo como um arquivo de banco de dados. Eu sei que muitos aplicativos Android usam o Sqlite3, talvez essa seja a causa.