size of uec images

[Eric Hammond]

Scott:

I think the vast majority of EC2 users won't care since we'll be using
the AMIs and not the image files.

The small percentage who do figure out how to "download, mount, modify,
bundle, upload, register" shouldn't have too much trouble adding
"resize" if the explanation is in the same place.

If the inode count is increased by using the "rsync -a" approach, you
might consider specifying -H to preserve hard links.  I don't know how
many hard links there are on a server install or how much time this
option adds, so perhaps a bit of research is in order.

--
Eric Hammond



Scott Moser wrote:
> 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
>