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: 100% 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
Shouldn't docker be using the docker-pool LV? Also, partitioning for Atomic is setup by their kickstart, not Anaconda.
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.
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.
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.
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.
(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
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.
This is being resolved with the "one big volume" in F27. Closing. https://pagure.io/atomic-wg/issue/281
Apparently I can't close this bug? Can someone else do so?