LVM Thin Provisioning通过thin pool实现存储超卖，本质是声明容量总和远超物理空间，仅实际写入时占用存储；其由data LV和metadata LV组成，需同卷组且metadata大小需合理配置（如1TiB data配12–24MiB metadata），创建thin LV不占空间但须监控data_percent防耗尽导致I/O挂起。
LVM Thin Provisioning 实现存储“超卖”，本质是让多个逻辑卷的声明容量总和远大于底层物理空间，但只在实际写入数据时才占用真实存储。这不是魔术，而是靠一套受控的延迟分配机制——关键在于正确搭建 thin pool 并持续监控。
thin pool 是超卖的唯一载体
它不是普通 LV，而是一个由两部分组成的复合结构：
- 一个 data LV（存放真实数据块）
- 一个 metadata LV（记录哪些块被哪个 thin LV 使用）
二者必须同属一个卷组，且 metadata 大小不能太小——默认值往往不够用。例如，1TiB 的 data LV 建议配 12–24MiB metadata 空间；若忽略这点，即使 data 还有空闲，也可能因 metadata 耗尽而无法创建新 thin LV。
创建可超卖的 thin pool
先确保卷组有足够空闲（建议预留 ≥20% 应对突发增长）：
lvcreate -L 100G --thinpool vg00/thinpool01
这条命令会自动创建配套的 data + metadata LV。如需精细控制 metadata 大小，显式指定：
lvcreate -L 100G --thinpool --poolmetadatasize 32M vg00/thinpool01
创建并使用超卖的 thin LV
每个 thin LV 只登记元数据，不立即占空间：
lvcreate -V 50G --thin --name vm101-disk vg00/thinpool01 lvcreate -V 50G --thin --name vm102-disk vg00/thinpool01
上面两条命令共声明了 100G 虚拟空间，但 thin pool 实际只用了几 MB。只要 data LV 没写满，就能继续创建更多 thin LV——比如 pool 仅 80G 物理空间，却挂了 5 个各 50G 的虚拟盘（总声明 250G），超卖率达 3.125 倍。
必须盯住 data_percent，否则会静默锁死
thin pool 没有写保护：data 空间真正耗尽时，新写入会阻塞，应用可能 hang 住。务必定期检查：
lvs -o+pool_lv,origin,data_percent,metadata_percent vg00
重点关注 data_percent。超过 80% 就该预警；达到 100% 时，I/O 将停滞。
让扩容自动化（推荐启用）
编辑 /etc/lvm/lvm.conf，设置：
thin_pool_autoextend_threshold = 80 thin_pool_autoextend_percent = 20
再开启监控：
lvchange --monitor y /dev/vg00/thinpool01
这样当 data 使用率突破 80%，LVM 会自动将 pool 扩大 20%（前提是 VG 中还有空闲 PE）。
删了 thin LV 不等于立刻释放空间
删除后空间不会马上还给 pool，需手动触发回收或等待内核自动清理：
lvconvert --thinpool vg00/thinpool01 --poolmetadatasize +1M
这条命令能强制刷新 metadata，加速空间回收。
超卖本身不难，难点在平衡利用率与稳定性——它不是省空间的捷径，而是需要主动运维的资源调度策略。
