I am building a disk image for an embedded system (to be placed on an 4GB SD card). I want the system to have two partitions. A 'Root'(200Mb), and a 'Data' partition(800Mb).
I create an empty 1GB file with dd.
Then I use parted to set up the partitions.
I mount them each in a loop device then format them; ext2 for 'Root' ext4 for 'Data'. Add my root file system to the 'Root' partition and leave 'Data' empty.
Here's where the problem is. I am now stuck with a 1GB image, with only 200MB of data on it. Shouldn't I, in theory, be able to truncate the image down to say.. 201MB and still have the file system mountable? Unfortunately I have not found this to be the case.
I recall in the past having used a build environment from Freescale that used to create 30Mb images, that would have partitions for utilizing an entire 4GB sdcard. Unfortunately, at this time, I can not find how they were doing that.
I have read the on-disk format for the ext file system, and if there is no data in anything past the first super block (except for backup super blocks, and unused block tables) I thought I could truncate there.
Unfortunately, when I do this, the mounting system freaks out. I can then run FSCK, restore the super blocks, and block tables, and can mount it then no problem. I just don't think that should be necessary.
Perhaps a different file system could work? Any ideas?
thanks,
edit
changed partition to read file system. The partition is still there and deoesn't change, but the file system is getting destroyed after truncating the image.
edit
I have found the case to be that when I truncate the file to a size just larger than the first set of 'Data' partition superblock and inode/block tables, (Somewhere in the data-block range) the file system becomes umountable without doing a fsck to restore the rest of the super blocks and block/inode tables
Best Answer
Firstly, writing a sparse image to a disk will not result in anything but the whole of the size of that image file - holes and all - covering the disk. This is because handling of sparse files is a quality of the filesystem - and a raw device (such as the one to which you write the image) has no such thing yet. A sparse file can be stored safely and securely on a medium controlled by a filesystem which understands sparse files (such as an ext4 device) but as soon as you write it out it will envelop all that you intend it to. And so what you should do is either:
Simply store it on an fs which understands sparse files until you are prepared to write it.
Make it two layers deep...
Which is to say, write out your main image to a file, create another parent image with an fs which understands sparse files, then copy your image to the parent image, and...
When it comes time to write the image, first write your parent image, then write your main image.
Here's how to do 2:
Create a 1GB sparse file...
Write two
ext4
partitions to its partition table: 1 200MB, 2 800MB...Create two
ext4
filesystems on a-P
artitioned loop device and put a copy of the second on the first...Now that's a lot of output - mostly from
mkfs.ext4
- but notice especially thels
bits at the bottom.ls -s
will show the actual-s
ize of a file on disk - and it is always displayed in the first column.Now we can basically reduce our image to only the first partition...
There
fdisk
tells us there are 411647 +1 512 byte sectors in the first partition ofimg
...That truncates the
img
file to only its first partition. See?...but we can still mount that partition...
...and here are its contents...
And we can append the stored image of the second partition to the first...
Now that has grown our
img
file: it's no longer sparse......but removing that is as simple the second time as it was the first, of course...