You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know there's been quite some tickets about "docker not cleaning up data", and in many cases there may be other issues at hand, but I got a bit confused myself when looking at some output on usage. I noticed this on a 23.0.1 install, but after that tried on 20.10.23 (with buildx 0.10), and got the same results;
Taking this build, which is started from a clean slate;
# syntax=docker/dockerfile:1FROM alpine AS one
RUN echo hello > /foo.txt
FROM golang AS two
RUN ls -la / && cd /usr && ls -la && echo bar > /bar.txt
FROM scratch AS final
COPY --from=one /foo.txt .
COPY --from=two /bar.txt .
After the build finishes, I have a single foo image tha only contains 2 files, so is small;
docker image ls -a
REPOSITORY TAG IMAGE ID CREATED SIZE
foo latest a3ae12bbce7d 34 minutes ago 10B
However, as the build progress output above shows, the build did use some images, which were pulled. When trying to find that data, docker system df only shows 10B (the foo image) and 239B (build cache) to be in use:
docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 0 10B 10B (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 15 0 239B 239B
Using the -v / --verbose output shows similar results:
docker system df -v
Images space usage:
REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS
foo latest a3ae12bbce7d 5 minutes ago 10B 0B 10B 0
Containers space usage:
CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES
Local Volumes space usage:
VOLUME NAME LINKS SIZE
Build cache usage: 239B
CACHE ID CACHE TYPE SIZE CREATED LAST USED USAGE SHARED
wyfsj52id80s regular 0B 5 minutes ago 5 minutes ago 1 false
sdgtrltmn9zq regular 0B 5 minutes ago 5 minutes ago 1 false
psmxf6wtltt0 regular 0B 5 minutes ago 5 minutes ago 1 false
85gxood4ghnd regular 0B 5 minutes ago 5 minutes ago 1 false
wypqolrskp6u regular 0B 5 minutes ago 5 minutes ago 1 false
umxq7wa2cspa regular 0B 5 minutes ago 5 minutes ago 1 false
my4jwwt7ul1e source.local 0B 5 minutes ago 5 minutes ago 1 false
jg87eoa3h5ev frontend 0B 5 minutes ago 5 minutes ago 1 false
7678jm6iiip8 regular 0B 5 minutes ago 5 minutes ago 1 false
ntuhwgdhid24 regular 4B 5 minutes ago 5 minutes ago 1 false
vsl0701q1lv3 regular 4B 5 minutes ago 5 minutes ago 1 true
qili2c1acuu8 source.local 229B 5 minutes ago 5 minutes ago 1 false
r8dy9usanuna regular 0B 5 minutes ago 5 minutes ago 1 false
yr2i4voof9dj regular 6B 5 minutes ago 5 minutes ago 1 false
lh2puk35z1oa regular 6B 5 minutes ago 5 minutes ago 1 true
Doing a naive du on docker's data location shows a whole different outcome though;
I wonder if this is because the build-cache is kept out of the image store, but if that's the case, why doesn't it report the size? Perhaps I'm overlooking something else though 😅
Description
I know there's been quite some tickets about "docker not cleaning up data", and in many cases there may be other issues at hand, but I got a bit confused myself when looking at some output on usage. I noticed this on a 23.0.1 install, but after that tried on 20.10.23 (with buildx 0.10), and got the same results;
Taking this build, which is started from a clean slate;
Which shows:
After the build finishes, I have a single
foo
image tha only contains 2 files, so is small;However, as the build progress output above shows, the build did use some images, which were pulled. When trying to find that data,
docker system df
only shows10B
(thefoo
image) and239B
(build cache) to be in use:Using the
-v
/--verbose
output shows similar results:Doing a naive
du
on docker's data location shows a whole different outcome though;That output shows various directories from those images used during build (partial output below);
Running
docker system prune
output roughly matches the amount that was reported bydocker system df
;And the data is properly cleaned up after this, so nothing really "leaked", but it's definitely confusing;
The text was updated successfully, but these errors were encountered: