Bug 1350027
Summary: | Overhaul default disk space allocations in Fedora Atomic Host | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Josh Berkus <josh> |
Component: | fedora-productimg-atomic | Assignee: | Colin Walters <walters> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 24 | CC: | anaconda-maint-list, g.kaviyarasu, jberkus, jonathan, josh, miabbott, vanmeeuwen+fedora, walters |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-07-26 12:48:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Josh Berkus
2016-06-24 21:03:56 UTC
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? |