Docker's Copy-on-Write Mechanism for Container Efficiency

> Format output of Docker commands with the `--format` option. > > The examples above use the `docker image inspect` command with the `--format` > option to view the layer IDs, formatted as a JSON array. The `--format` > option on Docker commands can be a powerful feature that allows you to > extract and format specific information from the output, without requiring > additional tools such as `awk` or `sed`. To learn more about formatting > the output of docker commands using the `--format` flag, refer to the > [format command and log output section](/manuals/engine/cli/formatting.md). > We also pretty-printed the JSON output using the [`jq` utility](https://stedolan.github.io/jq/) > for readability. ### Copying makes containers efficient When you start a container, a thin writable container layer is added on top of the other layers. Any changes the container makes to the filesystem are stored here. Any files the container doesn't change don't get copied to this writable layer. This means that the writable layer is as small as possible. When an existing file in a container is modified, the storage driver performs a copy-on-write operation. The specific steps involved depend on the specific storage driver. For the `overlay2` driver, the copy-on-write operation follows this rough sequence: * Search through the image layers for the file to update. The process starts at the newest layer and works down to the base layer one layer at a time. When results are found, they're added to a cache to speed future operations. * Perform a `copy_up` operation on the first copy of the file that's found, to copy the file to the container's writable layer. * Any modifications are made to this copy of the file, and the container can't see the read-only copy of the file that exists in the lower layer. Btrfs, ZFS, and other drivers handle the copy-on-write differently. You can read more about the methods of these drivers later in their detailed descriptions. Containers that write a lot of data consume more space than containers that don't. This is because most write operations consume new space in the container's thin writable top layer. Note that changing the metadata of files, for example, changing file permissions or ownership of a file, can also result in a `copy_up` operation, therefore duplicating the file to the writable layer. > [!TIP] > > Use volumes for write-heavy applications. > > Don't store the data in the container for write-heavy applications. Such > applications, for example write-intensive databases, are known to be > problematic particularly when pre-existing data exists in the read-only > layer. > > Instead, use Docker volumes, which are independent of the running container, > and designed to be efficient for I/O. In addition, volumes can be shared > among containers and don't increase the size of your container's writable > layer. Refer to the [use volumes](../volumes.md) section to learn about > volumes. A `copy_up` operation can incur a noticeable performance overhead. This overhead is different depending on which storage driver is in use. Large files, lots of layers, and deep directory trees can make the impact more noticeable. This is mitigated by the fact that each `copy_up` operation only occurs the first time a given file is modified. To verify the way that copy-on-write works, the following procedure spins up 5 containers based on the `acme/my-final-image:1.0` image we built earlier and examines how much room they take up. 1. From a terminal on your Docker host, run the following `docker run` commands. The strings at the end are the IDs of each container. ```console $ docker run -dit --name my_container_1 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_2 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_3 acme/my-final-image:1.0 bash \ && docker run -dit --name my_container_4 acme/my-final-image:1.0 bash \

This section elaborates on Docker's copy-on-write (CoW) mechanism, where containers have a thin writable layer on top of read-only image layers. Only changes are stored in this layer, minimizing space usage. When a file is modified, a 'copy_up' operation duplicates it to the writable layer. The section emphasizes that frequent writes increase container size and suggests using volumes for write-heavy applications due to their I/O efficiency and independence from the container's writable layer. Lastly, it mentions that while CoW can introduce performance overhead, it's a one-time operation per file modification. The following procedure demonstrates how containers based on the same image share layers to save space.