Understanding Device Mapper Thin Provisioning and Snapshots for Docker Storage

In the previous article we introduced AUFS and how Docker uses UnionFS for layered images; because AUFS is not in the main Linux kernel, non‑Ubuntu distributions like CentOS cannot use it, so Docker falls back to Device Mapper as a second‑priority storage driver.

Device Mapper Overview

Device Mapper, introduced in Linux 2.6, provides a generic kernel framework for logical volume management, exposing logical devices (Mapped Devices) that map to physical block devices (Target Devices) via a Mapping Table.

A Mapped Device can map to one or more Target Devices, and even to other Mapped Devices, allowing recursive, potentially infinite nesting similar to directories in a filesystem.

The framework uses modular Target Driver plugins to filter or redirect I/O requests; existing plugins include software RAID, encryption, multipath, mirroring, and snapshots. Thin Provisioning Snapshot is the most important module for Docker.

Thin Provisioning Overview

Thin Provisioning is a virtualization technique analogous to virtual memory: it presents virtually unlimited storage to the user while allocating physical space only when data is actually written, improving storage utilization.

The article shows two diagrams (Fat Provisioning vs. Thin Provisioning) to illustrate the concept.

Thin Provisioning Snapshot Demonstration

Below is a series of commands that demonstrate how to create a thin‑provisioned pool, volume, and snapshots using Device Mapper.

First, create two image files:

sudo dd if=/dev/zero of=/tmp/data.img bs=1K count=1 seek=10M

sudo dd if=/dev/zero of=/tmp/meta.data.img bs=1K count=1 seek=1G

The seek option skips the specified number of blocks, so the files appear large (10 GB and 1 GB) but initially occupy only a few kilobytes.

Verify the allocated size:

sudo ls -lsh /tmp/data.img

sudo ls -slh /tmp/meta.data.img

Associate each file with a loopback device:

sudo losetup /dev/loop2015 /tmp/data.img

sudo losetup /dev/loop2016 /tmp/meta.data.img

Create a thin‑provisioned pool:

sudo dmsetup create hchen-thin-pool \

--table "0 20971522 thin-pool /dev/loop2016 /dev/loop2015 128 65536 1 skip_block_zeroing"

Explanation of parameters:

0 – start sector

20971522 – number of sectors (10 GB)

/dev/loop2016 – metadata device

/dev/loop2015 – data device

128 – minimum allocatable sectors

65536 – low‑water mark

1 – additional parameter count

skip_block_zeroing – skip zero‑filling blocks

Check the created device:

sudo ll /dev/mapper/hchen-thin-pool

Create a thin volume inside the pool:

sudo dmsetup message /dev/mapper/hchen-thin-pool 0 "create_thin 0"

sudo dmsetup create hchen-thin-volumn-001 \

--table "0 2097152 thin /dev/mapper/hchen-thin-pool 0"

Format and mount the volume:

sudo mkfs.ext4 /dev/mapper/hchen-thin-volumn-001

sudo mkdir -p /mnt/base

sudo mount /dev/mapper/hchen-thin-volumn-001 /mnt/base

sudo echo "hello world, I am a base" > /mnt/base/id.txt

Create the first snapshot:

sudo dmsetup message /dev/mapper/hchen-thin-pool 0 "create_snap 1 0"

sudo dmsetup create mysnap1 \

--table "0 2097152 thin /dev/mapper/hchen-thin-pool 1"

Mount the snapshot and modify its contents:

sudo mkdir -p /mnt/mysnap1

sudo mount /dev/mapper/mysnap1 /mnt/mysnap1

sudo echo "I am snap1" >> /mnt/mysnap1/id.txt

sudo echo "I am snap1" > /mnt/mysnap1/snap1.txt

Observe that the original base volume remains unchanged, demonstrating copy‑on‑write snapshot behavior.

Create a second snapshot from the first one:

sudo dmsetup message /dev/mapper/hchen-thin-pool 0 "create_snap 2 1"

sudo dmsetup create mysnap2 \

--table "0 2097152 thin /dev/mapper/hchen-thin-pool 2"

Mount and verify that the second snapshot contains the files from the first snapshot.

Key theoretical points:

Snapshots originate from LVM and provide point‑in‑time copies without service interruption.

They use Copy‑On‑Write, copying data only when modifications occur.

Docker’s Device Mapper Usage

Docker creates loopback devices for its data and metadata files (e.g., 100 GB data, 2 GB metadata) and maps them via thin pools. Example commands show how to list loop devices, inspect the thin pool, and create a Docker snapshot.

Note that Device Mapper is still considered experimental for production use, and many practitioners recommend avoiding it in favor of other storage drivers.

These targets are very much still in the EXPERIMENTAL state. Please do not yet rely on them in production.

References: the article "Storage thin provisioning benefits and challenges" and various community discussions.