[CentOS-devel] Disk size on Vagrant image

Nico Kadel-Garcia

nkadel at gmail.com
Sun Aug 27 02:45:21 UTC 2017

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.

More information about the CentOS-devel mailing list