New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker.qcow2 never shrinks - disk space usage leak in docker for mac #371
Comments
Thanks for filing it over here @yakticus. I also still have the problem and in the forum others have reported the same: https://forums.docker.com/t/docker-doesnt-release-disk-space-used-by-library-containers-com-docker-docker/15194 |
+1 |
Yep, same issue here. |
I've found the quickest way (as mentioned in other issues / forum threads) to fix this is to reset the client which forces the recreation of NB: You'll need to install Connect to the VM with Fill up the disk with zeroes:
This'll take at least couple of minutes on SSD. I wouldn't bother if you're on spinning rust... Then you need to
|
@yankcrime's workaround works... but it's a lot of steps to make Docker not continuously gobble up all the remaining space on my poor little MacBook's SSD. Between this and osxfs perf issues (#77) requiring similarly involved file sync workarounds, it's really hard to recommend Docker for Mac to anyone who's not an infra hacker at heart... I don't want to have to spend half my day helping other devs figure out why all their disk space is gone! |
Just deleting it seems to be the easiest solution, but it would be nice if the client could reclaim space itself! |
I've been running into this issue as well on the latest Stable Docker for Mac. @yankcrime's workaround does work. Would be nice to be able to provide an option to grow the disk size as well. |
|
To add to this, I just deleted my qcow2 file and restart docker and disconnect completely from the internet, and ...1.14GB This is nuts. It'll happily just keep growing until it eats all of my available hard disk space. |
@chrisclark I have the same problem. There is no image, no container, qcow2 just keeping grow up, but until to 1.16GB. Seem 1.16GB is the VM basic requested working size. |
Same issue for me |
Yep! The same issue for me. If often rebuild my images it's trouble,headache! After 5-6 rebuild image has 1G size but disk space decrease on 20-30G!!!!! |
Can we have an update on this? It's a really big issue that needs solving. |
Using Docker to manage multiple development environments and this image often ends up to take 60GB for me. It's a lot on my 256GB SSD. All dev environments is using Docker Compose so I can reset docker once in a while but it's really annoying that I have to do so. |
I've been using Docker for Mac and the Docker Machine images in order to experiment effectively with Docker Swarm and other orchestration features -- the large qcow file and not-insubstantial disks of my other Docker Machine hosts make it difficult to fit onto a MBP sized HDD. Any update here? |
If you can remove all images/containers then:Stop Docker.
Start Docker, you have yours GB back. |
@wbednarski -- that's helpful if keeping images/containers around wasn't a big deal (as it might not be on a server) but it tends to be important in development (on my laptop.) I've read also that using the "Reset to factory defaults" button can clean up your installation too. Thanks for pointing out your solution. |
Didn't try reset. I'll check out it soon :] @anonymuse you can look at @yankcrime solution #371 (comment) if you want to keep images/containers. |
@yankcrime I tried as you said, but nothing changed.
|
Frank, how sure are you that you followed all of the steps correctly? Do I forgot to run the dd myself first time around! On Sep 23, 2016 12:07 PM, "Frank" notifications@github.com wrote:
|
@jackwiy Thanks, It works fine. |
hopefully the approach of @jackwiy works fine, thank you for that, by the way this is a serious issue in docker, that waste developer's time while building images, so we moved the container in an 4TB external disk thank to @shoegazerstella for the suggestion! |
@Glathrop I am also just a casual user and I consider it a fix. It takes no thought to use. |
It kind of eludes me why it is so hard to provide a button "Reclaim unused space" (and restart Docker.app afterwards to get an updated reading of the utilised disk space). |
<etc> The fact that Apple provides small SSDs to most MBP users statistically makes it crucial to have disk space available again ASAP after removing **some** images & containers for macOS users. </etc> This issue must be marked critical as it is very annoying bug.We see that
UPD: ANYONE, PLEASE READthis comment first for further discussion. I thought i did read the read, but there were so many comments, so it was hidden, but it is actually the explanation why it is very hard to fix. An here is a solution, the only one available besides resetting qcow2 disk fully: #371 (comment) I hope it helps to reduce further useless commenting :D |
i agree with @crackhd but i think problem also caused by how sierra and later handles volumes and files with punched-holes (continuous empty regions) i understand that they cannot use actual filesystem because of following reasons:
also given that majority of users who are using this in production are exclusively on linux and this does not affect them. |
any news on this? |
DockerEats @ 64 GB! https://www.flickr.com/photos/semerda/48720232588/ Running 'docker system prune' says: But when I check ~/Library/Containers/com.docker.docker/ for size after prune it still says 64.01 GB. Am I doing something wrong or is 'docker system prune' useless? And why the heck is Docker.raw file so colossal? |
@semerda read the discussion above; the |
Super annoying bug, I was thinking what takes that much space on my Mac... |
Whoa, this bug still persists after 3+ years? I just ran into this on the latest MacOS ( |
Mac thinks disk has no free memory (literally 0B for me frequently without disk reset). The image itself could be empty or contain only small images and containers. UPD: ANYONE, PLEASE READthis comment first for further discussion. I thought i did read the read, but there were so many comments, so it was hidden, but it is actually the explanation why it is very hard to fix. An here is a solution, the only one available besides resetting qcow2 disk fully: #371 (comment) I hope it helps to reduce further useless commenting :D |
@adam-lee to free space on the host the VM has to issue TRIM commands. It currently will execute an Perhaps give it a kick with
If you are using
If you are using |
@djs55 at least for me this does nothing
|
Ah - maybe this is a physical vs logical issue.
|
@djs55 your fix worked for me, at least for now. Thank you! Very frustrating that these bugs keep being closed/ignored. This is a fundamental resource leak, not something like a tiny UI issue that may get fixed by happenstance as someone does some refactoring. It's not something that you can close due to "inactivity." The fact that macOS is different and makes it difficult is irrelevant. I mean, isn't it concerning that the "official fix" is to download a container and run it? Shouldn't that just be a part of Docker for Mac? Especially when that fix is very hard to find. I ran across several other GitHub issues and Stack Overflow questions, all with varying solutions, until I found this thread. I tried reinstalling Docker, all sorts of wasted time. Should this not run during the uninstall, at the very least? Because reinstalling didn't fix the issue, either. I uninstalled with the uninstall built into Docker for Mac and it still didn't fix the issue. This means the uninstaller does NOT actually uninstall Docker. This seems rather alarming to me, and would clearly be unacceptable for any other desktop software. |
Total fail.
When I should have a maximum of 8 to 10 GB in there. So that does not work. Full stop. |
Note the different utilities report file sizes in different ways. When I use
but when I use
That's fair, given that I have a substantial # of images and containers:
|
There are countless posts here explaining how sparse images work, and why different tools will report different sizes. Yet every few days a new person jumps into the thread with a snarky comment incorrectly showing their huge image. Can y’all try to read the thread before posting please. |
Maybe this should be extracted into the official docs to improve the overall discoverability of the issue? After all this thread contains a few hundred replys |
Quoting from https://docs.docker.com/docker-for-mac/space/
|
This Stack Overflow thread fairly succinctly explains the high level cause and a quick solution (not perfect, but I was happy with it): https://stackoverflow.com/questions/49887747/what-is-docker-qcow2 Although I thought this behaviour was odd at first, after reading the SO thread, this doesn't really seem like a bug. Maybe Docker for Mac should default to a smaller disk image size (16GB vs 64GB)? |
I've tried this to trigger a manual TRIM from this blog:
|
@wanliqun link has extra parenthesis at the end :) Should be:
Btw since el-capitan got EOL (1) and Sierra (10.12) has APFS support (2), |
From the linked stackoverflow answer (emphasis mine):
Do you consider that a solution?! |
See https://github.com/wanliqun/macos_docker_toolkit – that seems to do the trick. On my end |
Hi
|
I just got the error For me, |
Expected behavior
Amount of disk space used under ~/Library/Containers/com.docker.docker/ should shrink when deleting images and/or containers
Actual behavior
Amount of disk space used under ~/Library/Containers/com.docker.docker/ doesn't shrink after deleting ~50 containers and ~141 images (out of a total of 194). My Docker.qcow2 was 41GB both before and after doing these deletions.
On the Diagnose & Feedback screen I see an error that looks relevant:
Information
For some history, see moby/moby#23437
I might not have this anymore since I had to do a factory reset in order to reclaim the disk space. After the factory reset, it is: 5F7A165B-83AC-4514-AFC4-DB53430D2E9D
Easy to reproduce by pulling some images, observing the size of Docker.qcow2, deleting the images and seeing that the size of Docker.qcow2 does not change. Let me know if more info is needed
OSX 10.11.6
Steps to reproduce the behavior
Transcript:
The text was updated successfully, but these errors were encountered: