size of docker.img

[caplam]

Hello,

I read the docker faq but i'am still stuck. For what i have seen all path are mapped outside the docker image.

My docker.img is 40GB large and used at 91%. It's growing.

I have 47 containers (50 images).

I searched without success which container was filling up the image.

I don't understand how are organized docker volumes.

For example in /var/lib/docker/btrfs/subvolumes i have 494 folders for a size of 163G.

I suspect i have duplicate volumes but i don't know how to detect them.

I have portainer installed and with it i deleted all unused volumes; i gained 1G (164G -> 163G).

Where can i start ? 

[itimpi]

If the usage of docker.img is growing then you have some path that is not mapped externally that should be.

 

Have you tried clicking on the button to calculate the container size on the Docker tab?   Doing that often makes it obvious which container is the problem.

[testdasi]

Beside docker mapping, the settings of the app itself may be a problem. For example, you might set mapping for Handbrake to map /output to cache but if your Handbrake settings itself sets output to /outputs then that /outputs is in the docker img.

 

Manually going through 47 dockers is quite a pain so what itimpi proposed probably is the best starting point.

 

Btw, 47 containers at 36GB is not exactly terrible (as long as your utlisation doesn't keep on growing). I have 26 dockers at 18GB, not too far off.

[caplam]

I destroyed my docker.img, currently redownloading containers. It's a pain in the ass with my slow connection.

Nothing obvious about the size of the containers.

Do you think upgrading the size on docker.img is the answer ?

I have seen there is a bug in btrfs which explain the size listed in /var/lib/docker/btrfs/subvolumes

When docker service was stopped and docker.img deleted, there was nothing in /var/lib/docker

As soon as i started reinstalling containers the subvolumes directory started to fill. I think there may be several duplicates in here.

Does it sound normal to you that i end up with subvolumes directory listed at 163GB?

 

[itimpi]

12 minutes ago, caplam said:

I destroyed my docker.img, currently redownloading containers. It's a pain in the ass with my slow connection.

Nothing obvious about the size of the containers.

Do you think upgrading the size on docker.img is the answer ?

I have seen there is a bug in btrfs which explain the size listed in /var/lib/docker/btrfs/subvolumes

When docker service was stopped and docker.img deleted, there was nothing in /var/lib/docker

As soon as i started reinstalling containers the subvolumes directory started to fill. I think there may be several duplicates in here.

Does it sound normal to you that i end up with subvolumes directory listed at 163GB?

 

If many containers share the same base Linux images (which is very likely) then their space may well end up being counted multiple times.    I would not have expected looking into the sub volumes directory to tell you anything useful.

 

If you do not start any of the containers you are now downloading then you can use the option to calculate the container size as the initial start point.    

[caplam]

For now i start a docker as soon as it's downloaded and i look at container size. I think it will end up tomorrow; it's so damn slow. 😱