I'm doing some Android development on Ubuntu 11.10.  I'm building a set of SD card and eMMC card Android images using a Bash script.Due to Android's idiosyncrasies, I have several file system images that need to be copied to the target card.  There are several lines in my script to copy over the images that look like this:image_dir=/some/directorynode=/dev/some/block/devicedd if=${image_dir}/data.img of=${node}; syncHere's where things get weird.  After partitioning the card and copying overdata.img using this dd command, there is a vast inconsistency between the size of the data.img on my dev machine and the amount of space taken up on the target SD card partition.For instance, the data.img file on my disk takes up 128 megabytes of space, roughly, but takes up almost 2.5 gigabytes on the partition of the SD card.  For obvious reasons, this is a serious problem.I've tried modifying the number of blocks dd reads and writes, but that didn't seem to change the amount of space required.  I've done a fair bit of googling, but I can't seem to find any references to problems like this.What can I do to fix this issue so the image doesn't take up so much space?  Could there be something wrong with the data.img file?  Am I using dd wrong?I've been tearing my hair out over this for a week, help me StackExchange, you're my only hope.EDIT: Question clarified above: It's not that the file system takes up a lot of space on the partition, it's that the partition is filled almost completely with data after running dd, despite the file system image being substantially smaller than said partition.
Why does a disk clone using dd take up more space on the target than the source image?
ubuntu;dd;android
The first thing that jumps to mind is files with holes. If a program opens a file, and uses the lseek() system call to set the file offset to greater than one file-system-block, then writes some bytes, the file system code only allocates a block for the data that got written. The first file-system-block does not get allocated.  If another program opens the file and reads some bytes in that file-system-block, it gets zero value bytes.A program can skip a block anywhere in the file, not just at the beginning. Thus, files with holes.Having a backup blow-up in size is not uncommon for linux/unix, but the culprit is usually something like a database file. I know a lot of Android apps use Sqlite3, perhaps that's the cause.