Bug 1350027 - Overhaul default disk space allocations in Fedora Atomic Host
Summary: Overhaul default disk space allocations in Fedora Atomic Host
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-productimg-atomic
Version: 24
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-06-24 21:03 UTC by Josh Berkus
Modified: 2017-07-26 12:48 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-26 12:48:53 UTC
Type: Bug

Attachments (Terms of Use)

Description Josh Berkus 2016-06-24 21:03:56 UTC
Description of problem:

If you choose "default partitioning" at install time, FAH allocates a maximum of 3GB to the sysroot regardless of how much space you have.  Since sysroot includes docker volumes, users can exhaust this space very quickly.

Version-Release number of selected component (if applicable):

Unsure of anaconda version.  It's in Fedora Atomic Host 24.

How reproducible:


Steps to Reproduce:
1. Install FAH on bare metal machine with 64GB disk
2. Check df and lvm setup

Actual results:

3. Sysroot will be only 2.9G, which will be already 60% full

Expected results:

3. Sysroot should be at least 10GB if there is space for it.

Additional info:

-bash-4.3# vgs
  VG            #PV #LV #SN Attr   VSize  VFree 
  fedora-atomic   1   4   0 wz--n- 59.13g 31.39g

    -bash-4.3# lvm lvextend -r fedora-atomic/root -L +2G
      /etc/lvm/archive/.lvm_localhost.localdomain_4462_1491119813: write error failed: No space left on device
    -bash-4.3# lsblk
    NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda                                   8:0    0 59.6G  0 disk
    ├─sda1                                8:1    0  200M  0 part /boot/efi
    ├─sda2                                8:2    0  300M  0 part /boot
    └─sda3                                8:3    0 59.1G  0 part
      ├─fedora--atomic-root             253:0    0    3G  0 lvm  /sysroot
      ├─fedora--atomic-swap             253:1    0  3.8G  0 lvm  [SWAP]
      ├─fedora--atomic-docker--poolmeta 253:2    0   64M  0 lvm  
      └─fedora--atomic-docker--pool     253:3    0 20.9G  0 lvm

Comment 1 Brian Lane 2016-06-24 21:28:39 UTC
Shouldn't docker be using the docker-pool LV?

Also, partitioning for Atomic is setup by their kickstart, not Anaconda.

Comment 2 Colin Walters 2016-06-24 21:31:03 UTC
Yeah, unfortunately the Fedora host has grown some, plus systemd persistent journal in play tends to take up space.

I wouldn't have a problem increasing it (6GB?).  One followon effect is our Vagrant boxes are just 10GB but I'm increasingly feeling that's too painful and we should bump to something large like 80GB and rely on qcow2 thinp.

Comment 3 Josh Berkus 2016-06-24 22:35:31 UTC
Docker doesn't use the pool for volumes.

We need to increase it based on the disk space available, not as a fixed amount.  It really should be something like:

Min: 2.5GB
Standard: 30% of available disk

This would let us allocate like this, in general:

Dockerpool: 30% of disk
Root: 30% of disk
Swap: 10% of disk or 0.5X RAM, which ever is smaller (see below)

This would still leave users 30 to 40% of their disk to expand into, without putting them in the situation where they have 30GB of disk left but the system is paralyzed due to full disk.

We also overallocate to swap (I have 200% of RAM, which seems like pure overkill).  Is that a static allocation also?

This is a more general issue that we're forcing users to get involved in partitioning their disks even for fairly common use-cases.  Given the poor UI of disk partitioning tools, that's a big blocker for adoption.

Title of bug changed to reflect the more general work.

Comment 4 Colin Walters 2016-06-25 12:48:08 UTC
We could consider decreasing the initial image pool size and hence leaving more for the root.

There's two technical halves to this whole picture:
 - This package for the default rootfs and swap
 - https://github.com/projectatomic/docker-storage-setup for everything else like the image pool

In general, it's actually going to be hard to get users out of dealing with storage, but what makes the whole picture *significantly* simpler is the overlay backend, but that isn't compatible with SELinux.

Comment 5 Josh Berkus 2016-06-25 22:58:53 UTC

We don't have to decrease anything.  With the default allocation, on a 64GB disk, only half the disk was allocated to anything.  The other half was completely unallocated.

Comment 6 Micah Abbott 2016-06-27 13:17:52 UTC
(In reply to Josh Berkus from comment #5)
> Colin,
> We don't have to decrease anything.  With the default allocation, on a 64GB
> disk, only half the disk was allocated to anything.  The other half was
> completely unallocated.

This BZ might be related to this behavior - https://bugzilla.redhat.com/show_bug.cgi?id=1337308

Comment 7 Fedora End Of Life 2017-07-25 21:17:19 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 8 Josh Berkus 2017-07-25 23:45:33 UTC
This is being resolved with the "one big volume" in F27.  Closing.


Comment 9 Josh Berkus 2017-07-25 23:46:20 UTC
Apparently I can't close this bug?  Can someone else do so?

Note You need to log in before you can comment on or make changes to this bug.