Only the base layer of an image is stored as a true subvolume. All the other
layers are stored as snapshots, which only contain the differences introduced
in that layer. You can create snapshots of snapshots as shown in the diagram
below.

![Snapshots diagram](/Users/baehyunsol/Documents/Rust/ragit/sample/docker/content/manuals/engine/storage/drivers/images/btfs_snapshots.webp?w=350&h=100)

On disk, snapshots look and feel just like subvolumes, but in reality they are
much smaller and more space-efficient. Copy-on-write is used to maximize storage
efficiency and minimize layer size, and writes in the container's writable layer
are managed at the block level. The following image shows a subvolume and its
snapshot sharing data.

![Snapshot and subvolume sharing data](/Users/baehyunsol/Documents/Rust/ragit/sample/docker/content/manuals/engine/storage/drivers/images/btfs_pool.webp?w=450&h=200)

For maximum efficiency, when a container needs more space, it is allocated in
chunks of roughly 1 GB in size.

Docker's `btrfs` storage driver stores every image layer and container in its
own Btrfs subvolume or snapshot. The base layer of an image is stored as a
subvolume whereas child image layers and containers are stored as snapshots.
This is shown in the diagram below.

![Btrfs container layers](/Users/baehyunsol/Documents/Rust/ragit/sample/docker/content/manuals/engine/storage/drivers/images/btfs_container_layer.webp?w=600)

The high level process for creating images and containers on Docker hosts
running the `btrfs` driver is as follows:

1. The image's base layer is stored in a Btrfs _subvolume_ under
   `/var/lib/docker/btrfs/subvolumes`.

2. Subsequent image layers are stored as a Btrfs _snapshot_ of the parent
   layer's subvolume or snapshot, but with the changes introduced by this
   layer. These differences are stored at the block level.

3. The container's writable layer is a Btrfs snapshot of the final image layer,
   with the differences introduced by the running container. These differences
   are stored at the block level.

## How container reads and writes work with `btrfs`

### Reading files

A container is a space-efficient snapshot of an image. Metadata in the snapshot
points to the actual data blocks in the storage pool. This is the same as with
a subvolume. Therefore, reads performed against a snapshot are essentially the
same as reads performed against a subvolume.

### Writing files

As a general caution, writing and updating a large number of small files with
Btrfs can result in slow performance.

Consider three scenarios where a container opens a file for write access with
Btrfs.

#### Writing new files

Writing a new file to a container invokes an allocate-on-demand operation to
allocate new data block to the container's snapshot. The file is then written
to this new space. The allocate-on-demand operation is native to all writes
with Btrfs and is the same as writing new data to a subvolume. As a result,
writing new files to a container's snapshot operates at native Btrfs speeds.

#### Modifying existing files

Updating an existing file in a container is a copy-on-write operation
(redirect-on-write is the Btrfs terminology). The original data is read from
the layer where the file currently exists, and only the modified blocks are
written into the container's writable layer. Next, the Btrfs driver updates the
filesystem metadata in the snapshot to point to this new data. This behavior
incurs minor overhead.

#### Deleting files or directories

If a container deletes a file or directory that exists in a lower layer, Btrfs