size of uec images

[Scott Moser]

Hello all,
   The folks working on UEC have found the 10G filesystem images that we
create in our UEC builds [1] to be a bit unwieldy [2].  In addition to
download times, the uncompress takes quite a while (in the order of 10
minutes on "normal" developer hardware), and the 10G image doesn't run on
the several of the default instance sizes in UEC.
   The 10G size was chosen for good reason [3] to target ec2.
(Essentially on ec2 you get a '/' partition that of whatever size you want
up to 10G with no cost.) We had been interested in keeping the 10G image
size to make UEC images identical to those of ec2.

   I started off trying to address this issue by producing a 2G image
along side the 10G image (named with a '-2G' suffix).  The result was a
bit surprising to me:
      |10G img  | 2G img
      |------------------
amd64 |  476M   | 222M
 i386 |  470M   | 216M

   The numbers in the table are the compressed image size for the 10G and
2G partitions. The filesystems are filled with somewhere around 635M of
filesystem data (per 'df').

The data were serving and storing for our 10G images are over 50%
compressed zeros.  Given that, I do not think it makes much sense for us
to serve the 10G images.  Rather, I think we should create the 2G image,
and make available a script that can create a larger filesystem image from
the smaller one.   Essentially, something like:
   truncate "--size=$new_size" "$new_image"
   mke2fs -j $new_image
   sudo mount -o loop,ro "${old_image}" /mnt/tmp1
   sudo mount -o loop "${new_image}" /mnt/tmp2
   rsync -a /mnt/tmp1/ /mnt/tmp2
   sudo umount /mnt/tmp1
   sudo umount /mnt/tmp2

We'd then do these operations before pushing the ec2 images to amazon.

I cant think of any negatives of this plan, but wanted to make sure I
wasn't missing something.  Anyone have thoughts ?

--
[1] http://uec-images.ubuntu.com/releases/karmic/
[2] https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/439868
[3] https://bugs.launchpad.net/ubuntu-on-ec2/+bug/308535