终于搞懂了devicemapper的来龙去脉

继续看docker的devicemapper(一种存储驱动，而Device Mapper是内核的一种块设备映射框架)，docker默认使用的是loop-lvm，初始化时创建了两个比较大的稀疏文件(100GB的data和2GB的metadata，实际使用多少占用多少)，并使用losetup命令将这两个文件"attach/mount"为两个loop设备(把文件映射为两个伪设备，虽然是伪设备，但是可以像普通块设备一样，对其进行格式化想要的文件系统，比如xfs，奇幻吧，loop这个词就是这样来的)，然后基于这两个loop伪设备创建100GB大小的thin-pool(又映射了一层，这个时候用到了linux内核提供的dm机制，可以使用dmsetup info命令查看)，基于这个thin-pool，每启动一个容器就从100GB里面分出来10GB空间给该容器，擦，整个来龙去脉终于搞懂了。

loop-lvm为默认，安装方便，只用于测试环境(使用docker info可以看到警告，不能用于生产环境，笑，我们生产环境就是用的默认的，不过一个vm只有一个容器，可能没有暴露问题，但是性能还是差一些的)，基于稀疏文件不仅读写性能差，也没有直接使用"块设备"稳定，于是devicemapper驱动程序还有另外一种方式，direct-lvm，准确说，这个才是真正的lvm，配置方式和配置lvm的方式一样的(比较繁琐和麻烦)，当然docker也提供了工具。另外，还看了docker的另外一个存储driver，overlay(最新的为overlay2，它也是分层的，不过只有两层，镜像层和容器层，aufs是很多层，devicemapper没有分层的概念，而是快照，不过快照好像也是分层的，前两者是基于文件系统的，后者也是基于块设备)，可以通