zeroing out the cloud image filesystem

[Andy Grimm]

On Tue, May 21, 2013 at 5:34 PM, Matthew Miller <mattdm at 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.

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 at fedoraproject.org>
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20130521/416168e9/attachment.html>