一、简介
Docker现在非常火热，作为docker存储引擎之一的dm thin pool用的比较多，thin-pool由一个metadata设备和data设备组成，thin的概念就是按需分配数据块，删除时也回收数据块，提高存储空间利用率。
a) Dm thin pool创建命令如下:
//清零metadata设备的第一个page, why??因为第一个page是thin-pool的superblock, thin pool 内核模块里是通过判断superbock是否全0来决定是重新格式化一个thin-pool还是打开已有的thin-pool
dd if=/dev/zero of=$metadata_dev bs=4096 count=1
//创建pool, --table的参数，0为起始扇区，20971520是扇区数，这里的扇区都是512字节来算的，data_block_size --- 数据块的大小，单位还是扇区，512字节，data_block_size最小为128,最大为2097152
low_water_mark ---当空闲数据块个数小于water_mark时， dm thin-pool内核模块会给用户态daemon发送通知事件。
dmsetup create pool
b) --table "0 20971520 thin-pool $metadata_dev $data_dev
- $data_block_size $low_water_mark"
//调用pool设备的message接口，创建thin设备，其中0是thin设备的id, 因为一个pool可以创建N个thin设备，所以需要一个id来区别开这些thin设备。
dmsetup message /dev/mapper/pool 0 "create_thin 0"
//为上面的thin设备创建/dev/dm-x 设备文件。
dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0"
二、thin-pool磁盘布局
a) data设备
data设备是以data_block_size，如果是128就是128*512=64KB 划分为块来管理的，data设备存储的全是数据，没有任何元数据，所以磁盘布局略。
b) Meta设备
c) 如图, meta设备的磁盘布局如上，meta设备的块大小为4KB, 第一个块是superblock, 代码里定义如下:
/*
Little endian on-disk superblock and device details.
*/
struct thin_disk_superblock {
__le32 csum; /* Checksum of superblock except for this field. */
__le32 flags;
__le64 blocknr; /* This block number, dm_block_t. */
__u8 uuid[16];
__le64 magic;
__le32 version;
__le32 time;
__le64 trans_id;
/*
Root held by userspace transactions.
*/
__le64 held_root;
__u8 data_space_map_root[SPACE_MAP_ROOT_SIZE];
__u8 metadata_space_map_root[SPACE_MAP_ROOT_SIZE];
/*
2-level btree mapping (dev_id, (dev block, time)) -> data block
*/
__le64 data_mapping_root;
/*
Device detail root mapping dev_id -> device_details
*/
__le64 device_details_root;
__le32 data_block_size; /* In 512-byte sectors. */
__le32 metadata_block_size; /* In 512-byte sectors. */
__le64 metadata_nr_blocks;
__le32 compat_flags;
__le32 compat_ro_flags;
__le32 incompat_flags;
} __packed;
d) 重要的字段:
l Magic: pool设备的magic: 27022010
l Data_space_map_root: 管理数据块设备使用空间(使用位图)的map_root结构
l Metadata_space_map_root: 管理元数据块设备使用空间(使用位图)的map_root结构
l Data_mapping_root: thin设备从虚拟块地址到数据块设备上真实地址的映射btree根块号
l Device_details_root: 所有thin设备的信息以btree的方式存到Device_details_root指向的根块上
l Data_block_size: 数据设备块大小 = data_block_size * 512B
l Meta_nr_blocks: 元数据设备总块数， 注元数据设备块大小为4KB
三、寻址
从thin设备的虚拟块地址到数据设备的实际块地址，thin-pool的寻址逻辑如下:
a) 先用thin设备的dev_id作为key， 从data_mapping_root指向的块所包含的btree根节点中，去查找thin设备所对应的数据映射btree的块号
b) 再用虚拟块号作为key从thin设备的数据映射btree里去查找实际的value, 查到的value就是数据块设备上对应的实际块号
c) 整个过程用伪代码如下:
block_t find_thin_block(dev_t dev_id, block_t block)
{
block_t thin_map_root;
//从data_map_root btree中以dev_id为key查找对应的值，结果为dev_id对应的thin设备的具体btree根节点所在的块
thin_map_root = btree_lookup(pool_data_map_root, dev_id);
//从meta设备上读出根节点
read_block(meta_dev, thin_map_root, &thin_map_tree);
//从btree中以thin的虚拟块block查找data设备对应的实际块
return btree_lookup(&thin_map_tree, block);
}
四、空间管理
a) 整个thin-pool模块里，所有的空间管理都是基于btree的。
b) 元数据块设备自身的空间管理: 这个是通过以Metadata_space_map_root为根块的btree来管理的，叶子节点存放的是管理空间的位图，与普通位图不同的是thin-pool的位图是一个单元2个位，一共能表示4个状态: 0为空闲，1为引用计数为1， 2位引用计数为2， 3表示引用计数>2, 需要从另一颗btree里去找实际的引用计数。
c) 数据块设备空间管理: 跟元数据块设备自身空间管理类似，数据块设备也是一颗btree， 叶子节点指向包含管理位图的块，当然这些块都是在元数据设备上的。
d) 空间释放：当引用bitmap里的引用计数变为0时， 块就变空闲了，这也就是thin设备的意义所在，不过，这需要上层文件系统discard的支持，thin-pool需要能知道哪些块上层不需要了，就可以减小位图的引用计数，释放块。
五、总结
thin-pool的存储格式还是比较清晰和简单的，总体看上面的布局结构图就已经很清晰了。