Device Mapper是一个基于kernel的框架，它增强了很多Linux上的高级卷管理技术。Docker的devicemapper驱动在镜像和容器管理上，利用了该框架的超配和快照功能。为了区别，本文使用Device Mapper指驱动中的框架，而devicemapper指Docker的存储驱动。
注意：商业支持的Docker Engine（CS-Engine）建议在RHEL和CentOS上使用devicemapper存储驱动。
Docker最初运行在Ubuntu和Devian上，并且使用AUFS作为存储后端。当Docker变得流行后，很多想使用它的公司正在使用RHEL。不幸的是，因为Linux主线kernel并不包含AUFS，所以RHEL并没有支持AUFS。
为了改变这种情况，Red Hat开发者研究将AUFS包含进kernel主线。最后，他们认为开发一种新的存储后端是更好的主意。此外，他们打算使用已经存在的Device Mapper技术作为新存储后端的基础。
Red Hat与Docker公司合作贡献这个新驱动。因为这次合作，Docker Engine被重新设计为存储驱动插件化。因此devicemapper成为Docker支持的第二个存储驱动。
Device Mapper在2.6.9之后就被何如Linux kernel主线，也是RHEL家族发布包的核心部分。这意味着devicemapper存储驱动基于稳定的代码，有着大量的工作产品和极强的社区支持。
devicemapper驱动把每个镜像和容器都存储在它自己的虚拟设备中，这些设备是超配的copy-on-write快照设备。Device Mapper技术工作在块级别而不是文件级别，也就是说devicemapper存储驱动的超配和copy-on-write操作直接操作块，而不是整个文件。
注意：快照也是使用的thin设备或者虚拟设备。
使用devicemapper时，Docker如下创建镜像：
▶devicemapper存储驱动创建一个thin池。
这个池是在块设备或者loop mounted sparse file上创建的。
▶然后创建一个基础设备。
该基础设备是一个带文件系统的thin设备。可以通过docker info命令中的Backing filesystem值，来查看后端使用的是哪种文件系统。
▶每个新的镜像（和镜像层）都是该基础设备的快照。
这些都是超配的copy-on-write快照。也就是说它们初始化的时候是空的，只有在有数据写向它们时，才会从池中消耗空间。
使用devicemapper，容器层是基于镜像的快照。和镜像一样，容器快照也是超配的copy-on-write快照。容器快照保存了容器的所有更新，当向容器写数据时，devicemapper按需从池中分配空间给容器层。
下图展示了一个thin池、基础设备和两个镜像。
如果你仔细观察图片，你会发现每个镜像层都是它下层的快照，镜像的最底层是池中基础设备的快照。这个基础设备是Device Mapper产生的，并不是一个Docker镜像层。
而容器又是镜像的一个快照，下图展示了两个容器在整个存储驱动的层次。
下图显示了在一个容器中读取一个块（地址是0x44f）的过程。
▶应用在容器中请求访问块0x44f。
因为容器是镜像的一个thin快照，它没有实际的数据。但它有指针，指向镜像栈中数据所在的镜像快照。
▶存储驱动根据指针找到对应镜像层a005的快照块0xf33。
▶devicemapper拷贝镜像快照中块0xf33的数据到容器内存中。
▶容器驱动将数据返回给请求应用。 写操作
使用devicemapper驱动，写数据到容器是通过一个按需分配操作来完成的。更新已有的数据使用了copy-on-write操作。不过Device Mapper是基于块存储的技术，所以这些操作都发生在块的级别。
例如，要对容器中的一个大文件作小的修改，devicemapper驱动不拷贝整个文件，它只拷贝要修改的内容对应的块，每个块大小为64KB。
向容器写55KB的数据：
▶应用向容器发起写56KB数据的请求；
▶按需分配操作给容器快照分配了一个新的64KB的块。
如果写的数据大于64KB，就需要分配多个块给容器快照。
▶数据写向新分配的块。