¿Por qué una copy de disco usando dd ocupa más espacio en el destino que la image de origen?

Estoy haciendo algo de desarrollo de Android en Ubuntu 11.10. Estoy construyendo un set de tarjetas SD y tarjetas eMMC con imágenes Android usando un script Bash.

Debido a la idiosincrasia de Android, tengo varias imágenes del sistema de files que deben copyrse en la tarjeta objective. Hay varias líneas en mi script para copyr sobre las imágenes que se ven así:

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

Aquí es donde las cosas se ponen raras. Después de particionar la tarjeta y copyr sobre data.img usando este command dd , hay una gran inconsistencia entre el tamaño del data.img en mi máquina de desarrollo y la cantidad de espacio ocupado en la partición de la tarjeta SD de destino.

Por ejemplo, el file data.img en mi disco ocupa aproximadamente 128 megabytes de espacio, aproximadamente, pero ocupa casi 2.5 gigabytes en la partición de la tarjeta SD. Por razones obvias, este es un problema grave.

Intenté modificar el número de bloques dd lee y escribe, pero eso no pareció cambiar la cantidad de espacio requerido. He hecho un poco de google, pero parece que no puedo encontrar ninguna reference a problemas como este.

¿Qué puedo hacer para solucionar este problema para que la image no ocupe tanto espacio? ¿Podría haber algún problema con el file data.img ? ¿Estoy usando dd mal?

Me he estado desgarrando por una semana, ayúdame StackExchange, eres mi única esperanza.

EDITAR: Pregunta aclarada arriba: no es que el sistema de files ocupe mucho espacio en la partición, es que la partición está casi llena de datos después de ejecutar dd , a pesar de que la image del sistema de files es sustancialmente más pequeña que dicha partición.

Lo primero que me viene a la mente es " files con agujeros ". Si un progtwig abre un file y usa la llamada al sistema lseek() para establecer el desplazamiento del file en más de un bloque de sistema de files, luego escribe algunos bytes, el código del sistema de files solo asigna un bloque para los datos que se escribieron. El primer bloque de sistema de files no se asigna. Si otro progtwig abre el file y lee algunos bytes en ese bloque de sistema de files, obtiene cero bytes de valor.

Un progtwig puede omitir un bloque en cualquier lugar del file, no solo al principio. Por lo tanto, "files con agujeros".

Tener una copy de security en el tamaño no es raro para Linux / Unix, pero el culpable suele ser algo así como un file de database. Sé que muchas aplicaciones de Android usan Sqlite3, quizás esa es la causa.