10th chunk of `content/manuals/engine/storage/drivers/device-mapper-driver.md`
1988f69303893d08182900c80479369eef8cc5b546d3764e0000000100000c20
When you start Docker with the `devicemapper` storage driver, all objects
related to image and container layers are stored in
`/var/lib/docker/devicemapper/`, which is backed by one or more block-level
devices, either loopback devices (testing only) or physical disks.
- The _base device_ is the lowest-level object. This is the thin pool itself.
You can examine it using `docker info`. It contains a filesystem. This base
device is the starting point for every image and container layer. The base
device is a Device Mapper implementation detail, rather than a Docker layer.
- Metadata about the base device and each image or container layer is stored in
`/var/lib/docker/devicemapper/metadata/` in JSON format. These layers are
copy-on-write snapshots, which means that they are empty until they diverge
from their parent layers.
- Each container's writable layer is mounted on a mountpoint in
`/var/lib/docker/devicemapper/mnt/`. An empty directory exists for each
read-only image layer and each stopped container.
Each image layer is a snapshot of the layer below it. The lowest layer of each
image is a snapshot of the base device that exists in the pool. When you run a
container, it is a snapshot of the image the container is based on. The following
example shows a Docker host with two running containers. The first is a `ubuntu`
container and the second is a `busybox` container.

## How container reads and writes work with `devicemapper`
### Reading files
With `devicemapper`, reads happen at the block level. The diagram below shows
the high level process for reading a single block (`0x44f`) in an example
container.

An application makes a read request for block `0x44f` in the container. Because
the container is a thin snapshot of an image, it doesn't have the block, but it
has a pointer to the block on the nearest parent image where it does exist, and
it reads the block from there. The block now exists in the container's memory.
### Writing files
**Writing a new file**: With the `devicemapper` driver, writing new data to a
container is accomplished by an *allocate-on-demand* operation. Each block of
the new file is allocated in the container's writable layer and the block is
written there.
**Updating an existing file**: The relevant block of the file is read from the
nearest layer where it exists. When the container writes the file, only the
modified blocks are written to the container's writable layer.
**Deleting a file or directory**: When you delete a file or directory in a
container's writable layer, or when an image layer deletes a file that exists
in its parent layer, the `devicemapper` storage driver intercepts further read
attempts on that file or directory and responds that the file or directory does