先来看看 docker devicemapper 插件工作原理吧
它是基于 Device Mapper 的“精简目标”的特性。它实际上是目标块设备的快照，之所以被称为“精简”是因为它允许精简配置。精简配置意味着你有一个（希望很大）可用存储块的池，接着你可以从那个池中创建任意大小的块设备（虚拟磁盘，如有需要）；在你实际读写后，这些存储块将会被标记为已使用（或者从池中拿走）。
这意味着你是可以超额使用这个池，比如在一个 100GB 的池里面创建几千个 10GB 的卷，甚至可能是一个 100TB 的卷在一个 1GB 的池里面。只要你的实际读写的块的容量不大于池的大小，你怎么做都 OK 。
除此之外，精简目标的方式是可以做快照的。这表明无论何时，你都可以创建一个存在的卷的浅拷贝。在用户看来，就像你有两个一样的卷，它们可以独立地各自修改。即使你做了一个完整的拷贝，除了在时间上它是瞬间发生的（即使是很大的卷），它们不会两次重复使用存储。额外的存储只有当其中任何一卷有变化的时候才会发生，然后精简目标会从池里面分配一个存储快。
从本质上来看，“精简目标”实际上使用了两个存储设备：一个（大）的是存储块池自己，还有一个小的存储了一些元数据。这些元数据中包括了卷、快照、以及每个卷的块或者快照同存储池中块的映射信息。
当 Docker 使用 Device Mapper 存储插件的时候，它会在 /var/lib/docker/devicemapper/devicemapper/data 和/var/lib/docker/devicemapper/devicemapper/metadata 下创建两个文件（如果它们不存在）来存储对应的存储池和相关的元数据。这非常方便，你不需要做任何安装部署的工作（你不需要额外的分区来存储 Docker 容器，或者建立 LVM 或其他类似的东西）。然而它也有两个缺点：
存储池会有一个默认 100GB 的容量
它将会被稀疏文件所支持。从磁盘的使用效率的观点来看，这还不错的（就像在精简池中的卷，它一开始是小的，只有当实际需要写的时候才会使用磁盘的存储块）。但是从性能的角度来看就不那么好了，因为 VFS 增加了一些额外的负担，特别是”第一次写的时候”。
下面我们来看看如何给容器进行扩容
使用灵活的方式进行资源分配
警告：下面的操作会删除你所有的容器和镜像，确保你已经把之前的数据做了备份！
LVM 逻辑卷的好处就是可以通过卷组来实时的进行资源分配，如果资源被分配多了，我们可以回收；当然更多的是在不够用的情况下，可以通过命令来分配更多的资源。
停止 Docker 守护进程，因为我们将要重新设置我们的存储插件，如果我们在运行的时候移除文件，那么糟糕的事情就将发生。
1、准备逻辑卷
/dev/volumegroup1/lv_date [300.00 GiB]
2、擦去 /var/lib/docker。（警告：正如前面提到的，这个操作会把你所有的容器和镜像都删除掉。你也可以选择 mv docker docker_bak）
mv /var/lib/docker/ /var/lib/docker_bak
3、创建一个存储目录：
mkdir -p /var/lib/docker/devicemapper/devicemapper
4、然后创建一个指向 /dev/mapper 设备的符号链接，重启 Docker
ln -s /dev/mapper/volumegroup1-lv_date /var/lib/docker/devicemapper/devicemapper/data
systemctl start docker.service
我们需要一个更快的池
警告：下面的操作会删除你所有的容器和镜像，确保你已经把之前的数据做了备份！
要获得一个更快速的池，最简单的办法就是使用一个真实的设备而不是一个基于文件的循环设备。过程几乎一样。假设你有一个完全空的硬盘， /dev/sdb，你想把它完全用于容器的存储，你可以这样做：
停止 Docker 守护进程
移除 /var/lib/docker （似曾相识，对么？）
创建一个存储目录： mkdir -p /var/lib/docker/devicemapper/devicemapper
在目录下创建一个数据软链接，指向设备：
ln -s /dev/sdb /var/lib/docker/devicemapper/devicemapper/data
重启 Docker
使用 docker info 来检查 Data Space Total 的值是否正确
