关于docker使用稀疏文件loop-lvm导致垃圾不能回收问题

CentOS/RHEL 的用户需要注意的事项
在 Ubuntu/Debian 上有 UnionFS 可以使用，如 aufs 或者 overlay2 ，而 CentOS 和 RHEL的内核中没有相关驱动。因此对于这类系统，一般使用 devicemapper 驱动利用 LVM 的一些机制来模拟分层存储。这样的做法除了性能比较差外，稳定性一般也不好，而且配置相对复杂。Docker 安装在 CentOS/RHEL 上后，会默认选择 devicemapper ，但是为了简化配置，
其 devicemapper 是跑在一个稀疏文件模拟的块设备上，也被称为 loop-lvm 。这样的选择是因为不需要额外配置就可以运行 Docker，这是自动配置唯一能做到的事情。但是 loop-lvm的做法非常不好，其稳定性、性能更差，无论是日志还是 docker info 中都会看到警告信息。官方文档有明确的文章讲解了如何配置块设备给 devicemapper 驱动做存储层的做法，这
类做法也被称为配置 direct-lvm 。

除了前面说到的问题外， devicemapper + loop-lvm 还有一个缺陷，因为它是稀疏文件，所
以它会不断增长。用户在使用过程中会注意到/var/lib/docker/devicemapper/devicemapper/data 不断增长，
而且无法控制。很多人会希望删除镜像或者可以解决这个问题，结果发现效果并不明显。原因就是这个稀疏文件
的空间释放后基本不进行垃圾回收的问题。因此往往会出现即使删除了文件内容，空间却无法回收，随
着使用这个稀疏文件一直在不断增长。所以对于 CentOS/RHEL 的用户来说，在没有办法使用 UnionFS 的情况下，
一定要配置direct-lvm 给 devicemapper ，无论是为了性能、稳定性还是空间利用率。或许有人注意到了 CentOS 7

中存在被 backports 回来的 overlay 驱动，不过 CentOS 里的这个驱动达不到生产环境使用的稳定程度，所以不推荐使用。

配置direct-lvm 给 devicemapper参考：http://blog.csdn.net/JackLiu16/article/details/79357917