On Wed, May 22, 2013 at 2:54 AM, Andy Grimm <agrimm(a)gmail.com> wrote:
On Tue, May 21, 2013 at 5:34 PM, Matthew Miller
<mattdm(a)fedoraproject.org>
wrote:
>
> On Wed, May 15, 2013 at 11:18:04AM -0400, Matthew Miller wrote:
> > > 2) I also commented out the "Zeroing out empty space"
postinstall
> > > stuff,
> > > because it drastically increases the image build time for not much
> > > benefit,
> > > IMHO.
> > One time image build cost vs. whatever benefit multipled by every time
> > the
> > image is used. :)
>
> To put some numbers behind it, the compressed qcow2 image with the dd to
> zero empty space is 215M out of appliance-creator. Without it, it's 242M.
Two things here: First, I did not mean to imply that I thought zeroing out
the disk was a completely useless operation. I merely was not willing to
pay the penalty for building my test image, and I was trying to be
completely honest about exactly how I built my image. Second, I think one
of the reasons this operation annoys me is that I'm used to using
ami-creator to create filesystem images (rather than full-disk images), and
in that scenario I start with a very small filesystem (1 GB or less) and
grow it after it's created. The idea of having a 10 GB disk, filling less
than 3% of its capacity, and then having to write zeros to the other 97%,
most of which was not actually needed for the install, seems pretty
suboptimal. If there are tools to optimize it (fstrim or whatever), that's
great. Otherwise, I'd be considering some hack like: make a small partition
on the disk, do the install, zero out bytes on the partition, and then
repartition.
And that's exactly what cloud-init can be used for. We're building our
images with 2G disk size and let cloud-init grow them to the max size
at boot which can be different for different flavors or if a user
creates a bootable volume with an arbitrary size.
...Juerg
I'm all for minimizing the size of whatever we make available for
download.
I also want people to feel like they can do their own test builds without
killing their hard drive. :-)
Andy
> If we use a smaller blocksize, or an incrementally shrinking one, we can
> shrink it by another megabyte, at the cost of even more build time. I
> think
> that's probably across the worth-it threshold, though.
>
> Using virt-sparsify seems to take even longer, but does get it down to
> 208M.
> That requires libguestfs, which we can't do in the current build system,
> but
> will be able to in the future one. (Feature rescheduled for F20.)
>
> --
> Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
> <mattdm(a)fedoraproject.org>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud