<blockquote>
<p>does Docker actually clone the image</p>
</blockquote>
<p>Typically no, it uses a layered filesystem, by default that's overlay2 on my systems. A decent example of this comes from the <a href="https://wiki.archlinux.org/index.php/Overlay_filesystem" rel="nofollow noreferrer">arch wiki</a>:</p>
<blockquote>
<ul>
<li>The lower directory can be read-only or could be an overlay itself.</li>
<li>The upper directory is normally writable.</li>
<li>The workdir is used to prepare files as they are switched between the layers.</li>
</ul>
<p>The lower directory can actually be a list of directories separated by
:, all changes in the merged directory are still reflected in upper.</p>
<p>Example:</p>
<pre><code># mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work /merged
</code></pre>
</blockquote>
<hr />
<blockquote>
<p>how can I see the actual disk space used by a container?</p>
</blockquote>
<p>Docker will show you the disk used by all containers in a <code>docker system df</code>.</p>
<pre><code>$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          183       4         37.59GB   37.34GB (99%)
Containers      7         3         2.23kB    1.114kB (49%)
Local Volumes   10        1         4.816GB   305.8MB (6%)
Build Cache     511       0         20.49GB   20.49GB
</code></pre>
<p>For a container, this number is not static (unlike images that are read only), so I don't think this shows in any of the inspect commands. But you can see the underlying filesystems used:</p>
<pre><code>$ docker container inspect 056 --format '{{json .GraphDriver}}' | jq .
{
  &quot;Data&quot;: {
    &quot;LowerDir&quot;: &quot;/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6-init/diff:/home/docker/overlay2/22281f31287edf3342709add6123436540bd04dea60e474c961421e47b2dd58f/diff:/home/docker/overlay2/6a7a1eee38c2496928dff4741c2f9a1365f177a3e620ef7cf8adb816bba69b55/diff:/home/docker/overlay2/fcf371f07f06a42d328027281afb52c8044000cb51c4bb01a1f0dca2701062ec/diff:/home/docker/overlay2/89f8b12195e051bc439ac66d2bb299975884cdb229146dd570b1cac4011a08e6/diff:/home/docker/overlay2/d5a7a5c1c11746080d802b4dd076fd4d775099cb16b73d82c06db71e93b4e0c5/diff&quot;,
    &quot;MergedDir&quot;: &quot;/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/merged&quot;,
    &quot;UpperDir&quot;: &quot;/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff&quot;,
    &quot;WorkDir&quot;: &quot;/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/work&quot;
  },
  &quot;Name&quot;: &quot;overlay2&quot;
}
</code></pre>
<p>In this case, I can look at the disk usage of UpperDir to see how much space is used by that container:</p>
<pre><code>$ sudo du -sh /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff
80K     /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff
</code></pre>
<hr />
<p>The actual disk space used by a container includes the filesystem changes made by the container, since overlay is a copy-on-write filesystem. Each file changed is first copied to the container specific filesystem, even for a timestamp, permission, or owner change to the file metadata. This allows multiple containers to use the same immutable image layers without seeing changes made by the other containers.</p>
<p>Docker also keeps container logs, stdout and stderr, for each container. These logs are by default unlimited.</p>
<p>What you won't see is a full copy of the image filesystem, <strong>unless</strong> the overlay and similar graph drivers are unavailable to the docker engine. The fallback on an unsupported host filesystem, or kernel missing the needed features, is to use the <code>vfs</code> graph driver in docker, which I believe is the same as the <code>native</code> snapshotter in containerd. I see this happen occasionally with a docker-in-docker build environment where you cannot run an overlay filesystem on top of the overlay container filesystem (the fix there is typically to mount a volume that is on a supported filesystem outside of the container's overlay filesystem).</p>

CC BY-SA 4.0
2020-12-10T14:08:43.220Z
2020-12-15T15:36:17.013Z
2020-12-15T15:36:17.013Z
BMitch
<p>Docker containers are processes, does a process use disk space ? nope (at least not in itself).</p>
<p>The space used is the space when you put the program on disk first (the container image here).</p>
<p>Starting a container multiple times behave as starting bash/zsh/ multiple times when you login/ssh on different terminals/sessions.</p>
<p>One particularity of containers, more precisely of overlayfs, is the layers, if you pull two images for services based on the same base image, the initial layer won't be downloaded twice.</p>
<p>A rought illustration:</p>
<pre><code>- Ubuntu 20.04
|- redis (FROM ubuntu 20.04)
|- apache2 (FROM ubuntu 20.04)
</code></pre>
<p>You can get image for apache2 and redis and get only 3 layers on disk, the base ubuntu 20.04 will be reused.</p>
<p>Refer to <a href="https://devops.stackexchange.com/a/12955/13">BMitch</a>'s answer for details</p>

CC BY-SA 4.0
2020-12-10T22:58:57.617Z
But when I delete a container and create a new one from the same image, the changes that I made in the first container are not persisted, i.e. the filesystem was reset; so the container does have a storage of its own somehow? Sorry I'm completely new to Docker.
BenMorel
CC BY-SA 4.0
2020-12-11T12:15:32.003Z
Each container start from the image and get its own place, like booting from an iso image or creating multiple vms from the same template
Tensibai
CC BY-SA 4.0
2020-12-11T13:02:06.097Z
This "own place" is the whole point of my question, I still find it hard to understand where/how this is actually stored.
BenMorel
CC BY-SA 4.0
2020-12-14T08:08:42.657Z
It is stored somewhere in /var/lib/docker usually, the "layer" dedicated to the container only exists with the container, when you remove the container it is deleted.
Tensibai
CC BY-SA 4.0
2020-12-10T21:20:38.997Z
2020-12-10T21:20:38.997Z
Tensibai
<p><strong>Update:</strong> in addition to answers already provided, you can also check space consumed by containers using:</p>
<pre><code>docker ps --size
</code></pre>
<p>The output will look like:</p>
<pre><code>CONTAINER ID   IMAGE     COMMAND        (...)    SIZE
172c7203b44a   ubuntu    &quot;/bin/bash&quot;    (...)    114MB (virtual 191MB)
</code></pre>
<p>Where:</p>
<ul>
<li><strong><code>114MB</code> is the size actually taken by the container</strong>, i.e. the upper layer of the filesystem;</li>
<li><code>virtual 191MB</code> is the size of the full filesystem, as seen by the container, which includes the 77 MB of the upper <code>ubuntu</code> layer.</li>
</ul>
<p>The upper <code>ubuntu</code> layer will be shared by all containers based on that image, so the 77 MB will only occupy space once, even if you start several containers from this image.</p>

CC BY-SA 4.0
2024-07-30T12:53:22.237Z
2024-07-30T12:53:22.237Z
BenMorel
<p>Yes, docker containers when they are running can take up some space as per your workload and application but as mentioned in the other answers - containers are built over layered filesystem therefore only extra space they consume is from some file/object they create/download during runtime which is not the part of base image like some debug log files, etc.</p>
<p>For ex. - When you run 100 containers of a base image of size 1GB, docker will not consume 100 GB of disk space as it leverages layered filesystem and top immutable layer is shared across all containers of same image.</p>
<p>When you stop and remove (yes!, remove explicitly or use <code>--rm</code> flag with <code>docker run</code> command) a container then it's space is reclaimed.</p>
<p>To check space used by containers (and other objects), you can use:</p>
<p><code>$ docker system df</code> and for detailed info. use verbose flag <code>$ docker system df -v</code></p>
<p>Initially when you start a container the SIZE column will show 0B but as soon as you start writing to the disk SIZE will change.</p>
<p>EDIT: added more info. as suggested by @Benjamin in comments</p>

CC BY-SA 4.0
2020-12-13T16:44:54.320Z
Thank you; is there a way I can see the actual disk space used by each container, on top of immutable layers?
BenMorel
CC BY-SA 4.0
2020-12-13T16:48:30.740Z
try `docker system df -v`. For more see - https://docs.docker.com/engine/reference/commandline/system_df/
Oli
CC BY-SA 4.0
2020-12-13T20:53:11.967Z
`docker system df -v` does output the actual disk space used by a container, in the `SIZE` column. It's indeed 0 bytes when I start the container, then starts showing a non-zero size as soon as I start writing to disk. You should probably add that to your answer!
BenMorel
CC BY-SA 4.0
2020-12-15T04:28:26.773Z
Thanks! @Benjamin will do.
Oli
CC BY-SA 4.0
2022-07-01T21:36:50.093Z
When you run 100 containers of a base image of size 1GB how much space would they consume?
alper
CC BY-SA 4.0
2020-12-13T07:52:20.943Z
2020-12-15T05:41:36.387Z
2020-12-15T05:41:36.387Z
Oli
<p>When I list my Docker images, I can see their sizes:</p>
<pre><code>$ sudo docker image ls

REPOSITORY                TAG                          IMAGE ID       CREATED         SIZE
travisci/ci-ubuntu-1804   packer-1606831264-7957c7a9   0a7a71407638   8 days ago      15.6GB
travisci/ci-ubuntu-1804   packer-1593521720-ca42795e   6093ba41f031   5 months ago    12.3GB
travisci/ci-sardonyx      packer-1547455648-2c98a19    d1b323af5b2a   23 months ago   9.02GB
</code></pre>
<p>However, docker containers do not display the space used:</p>
<pre><code>$ sudo docker container ls

CONTAINER ID  IMAGE         COMMAND       CREATED         STATUS         PORTS  NAMES
5794ae898b68  6093ba41f031  &quot;/sbin/init&quot;  10 minutes ago  Up 10 minutes         travis
762e3f8df2da  0a7a71407638  &quot;/sbin/init&quot;  4 hours ago     Up 4 hours            distracted_noyce
</code></pre>
<p>Of course, I understand that if you're writing to containers, some space <em>will</em> be used on the hard drive.</p>
<p>But when you create a container, <strong>does Docker actually clone the image</strong> before booting up the container? Or does it work with diffs, only storing the differences between the image and the current container disk state?</p>
<p>And, <strong>how can I see the actual disk space used by a container?</strong></p>

<docker>
Do Docker containers take up space?
BenMorel
# Do Docker containers take up space?

(Asked by: username_0 on 2020-12-10)

When I list my Docker images, I can see their sizes:
$ sudo docker image ls

REPOSITORY                TAG                          IMAGE ID       CREATED         SIZE
travisci/ci-ubuntu-1804   packer-1606831264-7957c7a9   0a7a71407638   8 days ago      15.6GB
travisci/ci-ubuntu-1804   packer-1593521720-ca42795e   6093ba41f031   5 months ago    12.3GB
travisci/ci-sardonyx      packer-1547455648-2c98a19    d1b323af5b2a   23 months ago   9.02GB

However, docker containers do not display the space used:
$ sudo docker container ls

CONTAINER ID  IMAGE         COMMAND       CREATED         STATUS         PORTS  NAMES
5794ae898b68  6093ba41f031  "/sbin/init"  10 minutes ago  Up 10 minutes         travis
762e3f8df2da  0a7a71407638  "/sbin/init"  4 hours ago     Up 4 hours            distracted_noyce

Of course, I understand that if you're writing to containers, some space will be used on the hard drive.
But when you create a container, does Docker actually clone the image before booting up the container? Or does it work with diffs, only storing the differences between the image and the current container disk state?
And, how can I see the actual disk space used by a container?

**Tags:** docker


---

## 4 answers

### Answer by username_3 on 2020-12-13. Score: 11 | Accepted answer

Yes, docker containers when they are running can take up some space as per your workload and application but as mentioned in the other answers - containers are built over layered filesystem therefore only extra space they consume is from some file/object they create/download during runtime which is not the part of base image like some debug log files, etc.

For ex. - When you run 100 containers of a base image of size 1GB, docker will not consume 100 GB of disk space as it leverages layered filesystem and top immutable layer is shared across all containers of same image.

When you stop and remove (yes!, remove explicitly or use `--rm` flag with `docker run` command) a container then it's space is reclaimed.

To check space used by containers (and other objects), you can use:

`$ docker system df` and for detailed info. use verbose flag `$ docker system df -v`

Initially when you start a container the SIZE column will show 0B but as soon as you start writing to the disk SIZE will change.

EDIT: added more info. as suggested by @Benjamin in comments

> **Comments:**
> **username_0**: Thank you; is there a way I can see the actual disk space used by each container, on top of immutable layers?  
> **username_3**: try `docker system df -v`. For more see - https://docs.docker.com/engine/reference/commandline/system_df/  
> **username_0**: `docker system df -v` does output the actual disk space used by a container, in the `SIZE` column. It's indeed 0 bytes when I start the container, then starts showing a non-zero size as soon as I start writing to disk. You should probably add that to your answer!  
> **username_3**: Thanks! @Benjamin will do.  
> **username_4**: When you run 100 containers of a base image of size 1GB how much space would they consume?  

---

### Answer by username_1 on 2020-12-10. Score: 3

does Docker actually clone the image

Typically no, it uses a layered filesystem, by default that's overlay2 on my systems. A decent example of this comes from the arch wiki:


The lower directory can be read-only or could be an overlay itself.
The upper directory is normally writable.
The workdir is used to prepare files as they are switched between the layers.

The lower directory can actually be a list of directories separated by
:, all changes in the merged directory are still reflected in upper.
Example:
# mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work /merged




how can I see the actual disk space used by a container?

Docker will show you the disk used by all containers in a docker system df.
$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          183       4         37.59GB   37.34GB (99%)
Containers      7         3         2.23kB    1.114kB (49%)
Local Volumes   10        1         4.816GB   305.8MB (6%)
Build Cache     511       0         20.49GB   20.49GB

For a container, this number is not static (unlike images that are read only), so I don't think this shows in any of the inspect commands. But you can see the underlying filesystems used:
$ docker container inspect 056 --format '{{json .GraphDriver}}' | jq .
{
  "Data": {
    "LowerDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6-init/diff:/home/docker/overlay2/22281f31287edf3342709add6123436540bd04dea60e474c961421e47b2dd58f/diff:/home/docker/overlay2/6a7a1eee38c2496928dff4741c2f9a1365f177a3e620ef7cf8adb816bba69b55/diff:/home/docker/overlay2/fcf371f07f06a42d328027281afb52c8044000cb51c4bb01a1f0dca2701062ec/diff:/home/docker/overlay2/89f8b12195e051bc439ac66d2bb299975884cdb229146dd570b1cac4011a08e6/diff:/home/docker/overlay2/d5a7a5c1c11746080d802b4dd076fd4d775099cb16b73d82c06db71e93b4e0c5/diff",
    "MergedDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/merged",
    "UpperDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff",
    "WorkDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/work"
  },
  "Name": "overlay2"
}

In this case, I can look at the disk usage of UpperDir to see how much space is used by that container:
$ sudo du -sh /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff
80K     /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff


The actual disk space used by a container includes the filesystem changes made by the container, since overlay is a copy-on-write filesystem. Each file changed is first copied to the container specific filesystem, even for a timestamp, permission, or owner change to the file metadata. This allows multiple containers to use the same immutable image layers without seeing changes made by the other containers.
Docker also keeps container logs, stdout and stderr, for each container. These logs are by default unlimited.
What you won't see is a full copy of the image filesystem, unless the overlay and similar graph drivers are unavailable to the docker engine. The fallback on an unsupported host filesystem, or kernel missing the needed features, is to use the vfs graph driver in docker, which I believe is the same as the native snapshotter in containerd. I see this happen occasionally with a docker-in-docker build environment where you cannot run an overlay filesystem on top of the overlay container filesystem (the fix there is typically to mount a volume that is on a supported filesystem outside of the container's overlay filesystem).


---

### Answer by username_2 on 2020-12-10. Score: 0

Docker containers are processes, does a process use disk space ? nope (at least not in itself).
The space used is the space when you put the program on disk first (the container image here).
Starting a container multiple times behave as starting bash/zsh/ multiple times when you login/ssh on different terminals/sessions.
One particularity of containers, more precisely of overlayfs, is the layers, if you pull two images for services based on the same base image, the initial layer won't be downloaded twice.
A rought illustration:
- Ubuntu 20.04
|- redis (FROM ubuntu 20.04)
|- apache2 (FROM ubuntu 20.04)

You can get image for apache2 and redis and get only 3 layers on disk, the base ubuntu 20.04 will be reused.
Refer to username_1's answer for details

> **Comments:**
> **username_0**: But when I delete a container and create a new one from the same image, the changes that I made in the first container are not persisted, i.e. the filesystem was reset; so the container does have a storage of its own somehow? Sorry I'm completely new to Docker.  
> **username_2**: Each container start from the image and get its own place, like booting from an iso image or creating multiple vms from the same template  
> **username_0**: This "own place" is the whole point of my question, I still find it hard to understand where/how this is actually stored.  
> **username_2**: It is stored somewhere in /var/lib/docker usually, the "layer" dedicated to the container only exists with the container, when you remove the container it is deleted.  

---

### Answer by username_0 on 2024-07-30. Score: 0

Update: in addition to answers already provided, you can also check space consumed by containers using:
docker ps --size

The output will look like:
CONTAINER ID   IMAGE     COMMAND        (...)    SIZE
172c7203b44a   ubuntu    "/bin/bash"    (...)    114MB (virtual 191MB)

Where:

114MB is the size actually taken by the container, i.e. the upper layer of the filesystem;
virtual 191MB is the size of the full filesystem, as seen by the container, which includes the 77 MB of the upper ubuntu layer.

The upper ubuntu layer will be shared by all containers based on that image, so the 77 MB will only occupy space once, even if you start several containers from this image.


---

