On Wed, May 22, 2013 at 2:54 AM, Andy Grimm <[email protected]> wrote: > On Tue, May 21, 2013 at 5:34 PM, Matthew Miller <[email protected]> > 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 ☁☁☁ >> <[email protected]> >> _______________________________________________ >> cloud mailing list >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/cloud > > > > _______________________________________________ > cloud mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/cloud > _______________________________________________ cloud mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/cloud
