Docker overlay2 eating Disk Space

Question

Below is the file system in overlay2 eating disk space, on Ubuntu Linux 18.04 LTS

Disk space of server 125GB

overlay         124G  6.0G  113G   6% /var/lib/docker/overlay2/9ac0eb938cd2a50bb87e8ed13605d3f09214fdd9c8967f18dfc3f9432701fea7/merged
overlay         124G  6.0G  113G   6% /var/lib/docker/overlay2/397b099799212060ee7a4718660aa13aba8aa1fbb92f4d88d86fbad94e572847/merged
shm              64M     0   64M   0% /var/lib/docker/containers/7ffb129016d187a61a31c33f9e468b98d0ac7ab1771b87631f6caade5b84adc6/mounts/shm
overlay         124G  6.0G  113G   6% /var/lib/docker/overlay2/df7c4acee73f7aa2536d2a8929a48241bc8e92a5f7b9cb63ab70cea731b52cec/merged

Cari

Answer 1

Another solution if the above doesn't work is setup a log rotation.

nano /etc/docker/daemon.json

if not found

cat > daemon.json

Add the following lines to file:

{
"log-driver": "json-file",
"log-opts": {
    "max-size": "10m",    
    "max-file": "3"    
    }
}

Restart the docker daemon: systemctl restart docker

Please refer: How to setup log rotation post installation

Cari

That helped me for sure! stackoverflow.com/questions/66410156 – Aran

Answer 2

In case someone else runs into this, here's what's happening:

Your container may be writing data (logs, deployables, downloads...) to its local filesystem, and overlay2 will create a diff on each append/create/delete, so the container's filesystem will keep growing until it fills all available space on the host.

There are a few workarounds that won't require changing the storage driver:

1. first of all, make sure the data saved by the container may be discarded (you probably don't want to delete your database or anything similar)

2. periodically stop the container, prune the system docker system prune and restart the container

3. make sure the container doesn't write to its local filesystem, but if you can't:

4. replace any directories the container writes to with volumes or mounts.

Marileemarilin

Periodically stopping container hosting a running service doesn't really help operations. A more permanent solution would. – Chemnitz

When I try this the command warns me that it will remove "all stopped containers". So stopping the containers and then running prune would DELETE the containers, wouldn't it? – Derrick

Yes. Just be sure you can pull/build them again! RTM: docs.docker.com/engine/reference/commandline/system_prune – Marileemarilin

Answer 3

If you are troubled by that /var/lib/docker/overlay2 directory is taking too much space(use du command to check space usage), then the answer below may be suitable for you.

1. docker xxx prune commands will clean up something unused, such as all stopped containers(in /var/lib/docker/containers), files in the virtual filesystems of stopped containers(in /var/lib/docker/overlay2), unmounted volumes(in /var/lib/docker/volumes) and images that don't have related containers(in /var/lib/docker/images). But all of this will not touch the containers which are in running.

2. limiting the size of logs in configurations will limit the size of /var/lib/docker/containers/*/*-json.log, but it doesn't involve the overlay2 directory.

3. you can find two folders called merged and diff in /var/lib/docker/overlay2/<hash>/. If these folders are big. That means there are high disk usage in your containers SELVES but not the docker host. In this case, you have to attach a terminal into relevant containers, find the high usage locations in the containers, and take your own solutions.

Just like Nick M said.

Chirr

Answer 4

I had a similar issue with the docker swarm. The docker system prune --volume, restarting the server, removing the swarm stack and recreation was not helping.

In my case, I was hosting RabbitMQ where docker-compose config was:

services:
  rabbitmq:
    image: rabbitmq:.....
    ....
    volumes:
      - "${PWD}/queues/data:/var/lib/rabbitmq"

In such a case each container restart, each server reboot, just all that leads to restarting the rabbitmq container takes more and more hard drive space.

Initial value:

ls -ltrh queues/data/mnesia/ | wc -l
61

du -sch queues/data/mnesia/
7.8G    queues/data/mnesia/
7.8G    total

After restart:

ls -ltrh queues/data/mnesia/ | wc -l
62

du -sch queues/data/mnesia/
8.3G    queues/data/mnesia/
8.3G    total

My solution was to stop the rabbitmq and remove directories in queues/data/mnesia/. Then restart the rabbitmq.

Maybe sth is wrong with my config... But if you have such an issue then worth checking your volumes of containers whether do not leave some trash there.

Basinger

Answer 5

Follow the Steps if your Server is Linux Ubuntu 18.04 LTS (should work for others too)

Docker info for Overlay2

Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true

if you got the following lines when you enter df -h --total

19M /var/lib/docker/overlay2/00d82017328c49c661c78ce14550c4073c50a550fe5004911bd3488b085aea76/diff
5.9M /var/lib/docker/overlay2/00e3e4fa0cbff7c242c38cfc9501ef1a523158d69b50779e08a773e7e22a01f1/diff
44M /var/lib/docker/overlay2/0e8e7e893b2c8aa17b4875d421670e058e4d97de066c970bbeab6cba566a44ba/diff
28K /var/lib/docker/overlay2/12a4c4e4877d35e9db657e4acff32e513042cb44119cca5c43fc19ad81c3915f/diff
............
............

then do the changes as follows:

First stop docker : sudo systemctl stop docker

Next: got to path /etc/docker

Check file daemon.json if not found

cat > daemon.json

and enter the following inside:

{
  "storage-driver": "aufs"
}

and close

Finally restart docker : sudo systemctl start docker

Check if the changes have been made:

Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 0
Dirperm1 Supported: true

Changing the file system can help you to resolve this issue.

Please if check your docker version supports aufs here:

Please do check the Linux distribution and what storage drivers supported here :

Cari

that’s bad advice these days. AuFS is deprecated on 19.03 – Goody