inconsistency between "docker system df" and Docker Desktop on Mac - docker

#docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 222 0 42.87GB 42.87GB (100%)
Containers 0 0 0B 0B
Local Volumes 10 0 77.68MB 77.68MB (100%)
Build Cache 946 0 7.982GB 7.982GB
From the docker system df command, it seems my docker disk is running out of space. But Docker desktop shows:
So I am confused which one should be the right one to indicate docker space usage?

If you're on a mac/windows, then it means that behind the scenes you're running a VM running linux. That disk size then corresponds to the VM disk size containing the Linux distro, rather than just the docker stuff.

Actually, the RECLAIMABLE column is basically the size and percentage of the resources that aren't in use, there is no container using these images/volumes. In your case, 100% of the images and volumes are in "Idle" so you can remove them if you want, there are some good ways to remove it like docker image prune and docker system prune.
The image that you sent has what you are looking for.

Related

Docker save can't export ~50GB image because no space, although I have 150GB free

I am simply trying to export a Docker image that I have so that I can push it to another system; however, I cannot even save it because of no space:
$ docker save mycustomimage:latest -o nessus.tar
Error response from daemon: write /var/lib/docker/tmp/docker-export-255300778/f2881cc25962de53a9f4efdbf759e88c86bd183abf773477ebbd5ddebc229ae8/layer.tar: no space left on device
However, if I run df -h, I can confirm that I have over 150GB of free space:
$ df -h
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk1s1 466Gi 275Gi 182Gi 61% 1290334 9223372036853485473 0% /
devfs 374Ki 374Ki 0Bi 100% 1296 0 100% /dev
/dev/disk1s4 466Gi 8.0Gi 182Gi 5% 8 9223372036854775799 0% /private/var/vm
map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net
map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home
drivefs 466Gi 292Gi 173Gi 63% 18446744069414640546 4294967295 32808793364899312% /Volumes/GoogleDrive
here's a list of the images:
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
mycustomimage/kali latest a1f226987b86 12 hours ago 33GB
mycustomimage/kali <none> ac3292dcbd65 4 months ago 25.1GB
mycustomimage/kali <none> 8a628403a803 6 months ago 12GB
I am not even sure if all of these images are 33GB combined, or 33GB is just the file size of the last image. It's just a simple Kali Linux docker with one custom tool on it that is about 5GB in space. I'm pretty sure that, if this image is 70GB large, then it's larger than my VM which has even more stuff installed.
Your df -h output corresponds with the output that I would expect to see on a mac, which means your linux containers are not running on the system where df -h was run.
If you are running the Docker Desktop for mac, then your docker daemon is running inside a hyperkit virtual machine that the whale icon Docker.app application manages in the background. This virtual machine includes a virtual disk with a finite size. The smallest configurable disk size for this disk image is 16GB. To see how much space your whale icon docker desktop managed virtual machine has, click on the whale icon, and choose "Preferences". Under the "Disk" tab, you will see how big the disk is, and how much space it is taking up (due to compression).
When the docker save command is run, the daemon will create a .tar at the location referenced in your error output, /var/lib/docker/tmp/.... Since your virtual machine's disk does not have enough space for that temporary .tar file, you get a disk out of space error.
To see the true amount of space available to the VM, run the following command:
docker run --rm -it -v /var/lib/docker/tmp:/r alpine df -h /r
It is possible to increase the amount of space your disk image has available to it, but keep in mind that will take up real space on your hard drive even once the large files are deleted from the filesystem on the disk image.
tldr; you are running docker in a virtual machine that has less space available to it than your host machine shows as available.
I pruned some images and containers and after that it worked.
docker image prune
and
docker container prune
https://docs.docker.com/config/pruning/

What is build cache in `docker system df`

run docker system df will display a row of Build Cache. What does this mean? In my machine this line is always showing 0 for all fields.
$ sudo docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 5 3 352.9MB 352.9MB (100%)
Containers 7 0 26.29MB 26.29MB (100%)
Local Volumes 1 1 0B 0B
Build Cache 0 0 0B 0B
The Build Cache lines refer to the cache used by BuildKit which is included with 18.09 and newer versions of docker. It is not enabled by default, so unless you have switched it on, you can expect this to read 0. This is the cache used when building and rebuilding images to speed up builds and reuse shared layers between images. It also reduces the size of the images pushed to a registry when layers are reused from prior builds.
The cache from BuildKit is buried since it runs from containerd rather than directly in docker, so you can view the disk used for this cache and then prune it with commands like:
docker builder prune
If you run builds without BuildKit, the cache for these will be cleaned up when you prune images on the host.
The command docker system df shows the docker disk usage.
Images shows the disk usage for the docker images that are not running.
Containers shows the disk usage for the docker containers running.
Local Volumes shows the disk usage for the volumes you are using on your running containers.
And, recently, it was added a new section called Build Cache, which shows the disk usage for the cache files docker is using while building and running containers.
It was not there before, it was added on May 18, 2018, but they forgot to add it to the documentation, so you can't see it listed on the system df docs.
I'd just sent a PR so you can see it on the example output so I hope they can merge it soon.
Edit:
The PR was merged, you can now find the examples on the official documentation.

How do I control the way docker determines if disk space is "reclaimable"?

In the spirit of this question, how does docker determine the 'reclaimability' of disk space used by the images and containers? An example of docker system df (which I have recently pruned):
>> xx:xx:xx > nope > docker >> docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 12 0 14.07GB 14.07GB (100%)
Containers 0 0 0B 0B
Local Volumes 7 0 817.1kB 817.1kB (100%)
Build Cache 0B 0B
Can I use the Dockerfile or docker-compose.yaml to manipulate or control how this designation is applied to disk space? For example, if I wanted to continually clean out a /mnt or /var/log in a container, service, or swarm based on some criteria (number of files, or their total size) is there a way to do that?
I've RTFM'd the v1.28 API doc but I only see references to SpaceReclaimed in the "Responses" section, neither did the prune documentation itself provide any clues (although I'm probably not understanding what --filter does).
The response to your question is no, there is no way to control the RECLAIMABLE number because Docker this a field calculate by summing the amount of space used by images that are not used by any container.
You can see my answer to the question you referred here.

What is the "RECLAIMABLE" space displayed in docker system df?

One can use the command docker system df (mirror) (introduced in Docker 1.13.0) to see docker disk usage, e.g.:
username#server:~$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 44 28 114.7GB 84.84GB (73%)
Containers 86 7 62.43GB 41.67GB (66%)
Local Volumes 2 1 0B 0B
Build Cache 0B 0B
How is the "RECLAIMABLE" displayed in docker system df computed? I.e., what does it represent?
The Docker documentation on docker system df (mirror) doesn't explain it. The Docker glossary (mirror) doesn't contain the term "RECLAIMABLE".
Hi #Franck Dernoncourt!
RECLAIMABLE is the space consumed by "unused" images (in the meaning of no containers based on thoses images is running).
In other words and as #jordanm said, this is the total size of images you can remove without breaking anything, that is exactly why Docker will remove them if you run docker system prune -a or docker image prune -a. The -a tells Docker to remove all unused images, without it Docker only removes dangling (untagged) images.
You can learn more on how optimize your disk space with Docker here and here and of course Docker documentation for docker image prune and docker system prune.
It's worth mentioning in addition to Kerat's answer, the command you may be looking for to free up space listed as RECLAIMABLE is docker system prune -a --volumes. Volumes will not be pruned by default if you don't include the --volumes flag.

How can my docker harddrive be bigger than the hosts?

I run some docker images on an EC2 host and recently noticed, that the docker FS is always 100GB. The host FS is only 8GB though.
What would happen, if i use more than 8GB on the docker image? Magic?
That comes from PR 14709 and the docker daemon --storage-opt dm.basesize= option:
Current default basesize is 10G. Change it to 100G. Reason being that for
some people 10G is turning out to be too small and we don't have capabilities
to grow it dyamically.
This is just overcommitting and no real space is allocated till container
actually writes data. And this is no different then fs based graphdrivers
where virtual size of a container root is unlimited.
So when you go over 8 GB, you should get a "No more space left on device" error message. No magic.

Resources