<div dir="ltr">On Tue, May 21, 2013 at 5:34 PM, Matthew Miller <span dir="ltr"><<a href="mailto:mattdm@fedoraproject.org" target="_blank">mattdm@fedoraproject.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 15, 2013 at 11:18:04AM -0400, Matthew Miller wrote:<br>
> > 2) I also commented out the "Zeroing out empty space" postinstall stuff,<br>
> > because it drastically increases the image build time for not much benefit,<br>
> > IMHO.<br>
> One time image build cost vs. whatever benefit multipled by every time the<br>
> image is used. :)<br>
<br>
To put some numbers behind it, the compressed qcow2 image with the dd to<br>
zero empty space is 215M out of appliance-creator. Without it, it's 242M.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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. :-)<br><br></div><div>Andy<br>
</div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If we use a smaller blocksize, or an incrementally shrinking one, we can<br>
shrink it by another megabyte, at the cost of even more build time. I think<br>
that's probably across the worth-it threshold, though.<br>
<br>
Using virt-sparsify seems to take even longer, but does get it down to 208M.<br>
That requires libguestfs, which we can't do in the current build system, but<br>
will be able to in the future one. (Feature rescheduled for F20.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <<a href="mailto:mattdm@fedoraproject.org">mattdm@fedoraproject.org</a>><br>
_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
</font></span></blockquote></div><br></div></div>