On Sat, Aug 26, 2017 at 2:18 AM, Laurentiu Pancescu <lpancescu at centosproject.org> wrote: > On 25/08/17 17:28, Jeff Sheltren wrote: >> >> A few questions as I look at >> https://github.com/lpancescu/sig-cloud-instance-build >> >> 1) I don't see where the 'dd' is happening, could you point to that? > > > Not implemented yet in CentOS, but reducing the image size is something I > intend to do as soon as 7.4.1708 is released. You can take a look at > Fedora's kickstart (no idea why they don't use zerofree, Fedora images only > use ext4): > > https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_242-246 Stop *right here*. OK, I went through pretty much this fun and games around 2001 working for Honking Big Proxy Service(tm). You're really going to hurt yourself trying to pre-optimize your disk images and shove them into a pre-allocated filesystem. Come listen to a story from an old timer. In those days of yore, with Red Hat 5.2, (not RHEL 5.2, Red Hat 5.2), an engineer thought much the way you did. "Build a complete disk image, but you have to 'dd' it to compress it and make it small enough, and we have different disk images, so we have to use 'dd' to fill it with zeroes and make it compress, so we need to do this one for each image and carry multiple images one for each disk size" You will hurt yourself doing this. Work from a tarball, *not-not-not* a disk image, built on a chroot cage. Apply modifications as needed. Compress *that* into a new tarball. Use the kickstart '%pre" tools to build your new file system, of whateve the !@#$ file you want, in a *much* faster and more flexible procedure than anything you can do from a disk image. Untar your contents into *that*, run a boot loader tool from inside the disk image built to whatever environment you want, and let kickstart procedures run on *that* at install time as needed to actually finish configuring the sytem. With sensibly written %pre and %post steps, you can *skip* most of the anaconda procedures and do whatever the heck you want with the available disk space, including setting up as small as feasible of a bootable disk and slapping the tarball onto it. >> 2) Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs? > > > "Strong" is somewhat subjective, but XFS is the default filesystem in CentOS > and some people ran out of inodes with our ext4 Vagrant images, without > running out of space. I wanted to go back to ext4 (with a small > bytes-per-inode parameter) and get rid of the swap partition, like Fedora > Cloud, but there was quite enthusiastic opposition in #centos-devel to > moving away from XFS. xfs is the standard for CentOS 7, not CentOS 6. For virtual purposes, it does support dynamic expansion of disks and partitions much more effectively than the "/" partition can be supported under ext4. I'd recommend it for that reason alone for such use, despite some personal confidence in the author of ext2, etc. (Ask privately if you're curious: I've known the boy a while.) > I started to go through the XFS documentation, to see if it's possible to > implement something similar to zerofree. I'm quite tired during the week > after work and commuting (there are constant traffic jams around Stuttgart - > think 35km one-way in 60-90 minutes), so progress is really slow. Brother, you've my sympathies. I set up for a while working in London spending weekends with my family, and staying at a cheap flatshare in Elephant and Castle. I was very productive, though it was rough on me and my family. I wound up buying every Robin Hobb book I could find for the 2 hour train commutes, and spent a fascinating month in Portsmouth one night due to dangerous hypoglycemia and a missed transfer. It got much better after 4:00 AM when I found the only all-night diner available and met very nice night people to chat up. Being the only native English speaker on a London bus at 2:00 AM was a frequent and fascinating experience.