can specify any of the block devices used to create the Btrfs filesystem.

   ```console
   $ sudo mount -t btrfs /dev/xvdf /var/lib/docker
   ```

   > [!NOTE]
   >
   > Make the change permanent across reboots by adding an entry to
   > `/etc/fstab`.

5. Copy the contents of `/var/lib/docker.bk` to `/var/lib/docker/`.

   ```console
   $ sudo cp -au /var/lib/docker.bk/* /var/lib/docker/
   ```

6. Configure Docker to use the `btrfs` storage driver. This is required even
   though `/var/lib/docker/` is now using a Btrfs filesystem.
   Edit or create the file `/etc/docker/daemon.json`. If it is a new file, add
   the following contents. If it is an existing file, add the key and value
   only, being careful to end the line with a comma if it isn't the final
   line before an ending curly bracket (`}`).

   ```json
   {
     "storage-driver": "btrfs"
   }
   ```

   See all storage options for each storage driver in the
   [daemon reference documentation](/reference/cli/dockerd/#options-per-storage-driver)

7. Start Docker. When it's running, verify that `btrfs` is being used as the
   storage driver.

   ```console
   $ docker info

   Containers: 0
    Running: 0
    Paused: 0
    Stopped: 0
   Images: 0
   Server Version: 17.03.1-ce
   Storage Driver: btrfs
    Build Version: Btrfs v4.4
    Library Version: 101
   <...>
   ```

8. When you are ready, remove the `/var/lib/docker.bk` directory.

## Manage a Btrfs volume

One of the benefits of Btrfs is the ease of managing Btrfs filesystems without
the need to unmount the filesystem or restart Docker.

When space gets low, Btrfs automatically expands the volume in chunks of
roughly 1 GB.

To add a block device to a Btrfs volume, use the `btrfs device add` and
`btrfs filesystem balance` commands.

```console
$ sudo btrfs device add /dev/svdh /var/lib/docker

$ sudo btrfs filesystem balance /var/lib/docker
```

> [!NOTE]
>
> While you can do these operations with Docker running, performance suffers.
> It might be best to plan an outage window to balance the Btrfs filesystem.

## How the `btrfs` storage driver works

The `btrfs` storage driver works differently from other
storage drivers in that your entire `/var/lib/docker/` directory is stored on a
Btrfs volume.

### Image and container layers on-disk

Information about image layers and writable container layers is stored in
`/var/lib/docker/btrfs/subvolumes/`. This subdirectory contains one directory
per image or container layer, with the unified filesystem built from a layer
plus all its parent layers. Subvolumes are natively copy-on-write and have space
allocated to them on-demand from an underlying storage pool. They can also be
nested and snapshotted. The diagram below shows 4 subvolumes. 'Subvolume 2' and
'Subvolume 3' are nested, whereas 'Subvolume 4' shows its own internal directory
tree.

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

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.