#197 Change size of Root, Docker partitions in F26 Atomic Host storage setup
Closed: Duplicate 2 years ago Opened 2 years ago by jberkus.

The way it is now:

Currently, the rootFS is sized at 3GB, fixed, and the Docker partition is 40% of the remaining space. This causes new users to run out of disk space if they do layering, ostree unlock, install a bunch of system containers, or even just run up the logs, even if they have plenty of physical disk space.

My suggestion for a new default is:

  • RootFS: 25% of disk space, with a minimum of 3GB and a maximum of 16GB
  • Docker Partition: 50% of total disk space (or 65% of remaining space), min 2GB
  • Unallocated: 25% of disk space.

This would mean, for a new install:

Disk Root Docker Unallocated
8GB 3GB 4GB 1GB
32GB 8GB 16GB 8GB
200GB 16GB 100GB 84GB


This should be easy to do with anaconda-based installs, but how would this work with images?

That's a very good question! And AWS images is one of the biggest places we need to have good default behavior ...

Presumably we can do this by changing the default cloud-init?

This should be easy to do with anaconda-based installs, but how would this work with images?

docker-storage-setup can do this for us. The images are only baked with an atomicos VG and an atomicos/root LV. docker-storage-setup does the rest on instance bringup.

This should be easy to do with anaconda-based installs, but how would this work with images?

docker-storage-setup can do this for us. The images are only baked with an atomicos VG and an atomicos/root LV. docker-storage-setup does the rest on instance bringup.

see my comment from another ticket where I did some investigation here on what is baked in the image (ignore the 9G part): https://pagure.io/atomic-wg/issue/186#comment-48868

I think we can simplify the rules to

  1. RootFS: 25% of disk space, with a minimum of 3GB and a maximum of 16GB
  2. Docker Partition: maximum of 50% of total disk space
  3. Leave anything else unallocated

No need to specify a rule for unallocated, really. We could warn if the total disk is under 5GB, leaving less than 2GB for docker. I'm pretty sure that results in the same results as your examples.

Question: what about swap?

Do we have any swap allocated, currently? I don't think we do.

Nit> Can we change this from Docker partition to Container Image partition.

I want to ask about the ratios. What is the unallocated space for? Are the ratios the same when overlay is used?

In openstack/magnum when overlay is used we extend the root lv to maximum since container images go there.

For devicemapper we use 5GB for root and all the rest for the pool.

Is it a bad practice?

The unallocated space is because we can't predict if the user will need more space for containers, or more for other things (a Gluster storage partition, for example). This means that, in the default case, the user can easily expand the partition where they run out of room.

I cases where you know more about your users than we do in the "default" case, you don't necessarily need the unallocated space.

BTW, if you know you won't want to migrate back, I recommend having a single partition with overlayFS (that is, DOCKER_ROOT_VOLUME=no). That way you don't have to guess at allocations at all.

@dwalsh

Maybe we should name the executable something other than "docker_storage_setup" then, no?

We are working on "de-dockerizing" this script. It will be renamed container_storage_setup.

Metadata Update from @dustymabe:
- Issue tagged with: host

2 years ago

Folding this issue into #281, which it's a subset of.

Metadata Update from @jberkus:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata