Linux LVM(五):Thin Provisioning 精简置备

字数 1557，阅读大约需 8 分钟

Thin Provisioning 是 LVM 最"省空间"的特性，也是最容易出问题的特性。本篇从原理到实战讲清 thin pool / thin LV / thin snapshot，以及如何避免"thin pool 满了"的灾难。

一、什么是 Thin Provisioning？

传统 LV：虚拟大小 = 实际占用。你要 100G，就必须给 100G。

Thin LV：虚拟大小可以大于实际占用。你说要 100G，实际可能只占 30G。

传统 LV：
  /dev/sdb (200G) →  vg_data (190G)  →  lv_app (100G,真实占 100G)

Thin LV：
  /dev/sdb (200G) →  vg_data (190G)
                              │
                              ├── thin pool tp_app (50G 实际空间)
                              │      │
                              │      ├── lv_thin1 (虚拟 100G,真实占 30G)
                              │      └── lv_thin2 (虚拟 100G,真实占 20G)
                              │
                              └── (剩余 140G)

适用场景：

• • 虚拟化（VM 磁盘普遍超分配）
• • 容器存储（开发测试环境）
• • 多租户（每个租户给一个"看上去"很大的盘）
• • 大量 thin snapshot（频繁打快照的场景）

二、创建 Thin Pool 和 Thin LV

2.1 两步创建

# 第 1 步：创建 thin pool（占用真实空间）
$ lvcreate -L 50G --thinpool tp_data vg_data
  Logical volume "tp_data" created.

# 第 2 步：从 thin pool 创建 thin LV（虚拟大小可大于 pool）
$ lvcreate -V 200G --thin -n lv_thin1 vg_data/tp_data
  Logical volume "lv_thin1" created.

参数说明：

2.2 验证

$ lvs
  LV       VG      Attr       LSize   Pool    Origin Data%  Meta%
  lv_thin1 vg_data Vwi-a-tz-- 200.00g tp_data          0.00   0.00
  tp_data  vg_data twi-aotz--  50.00g                 0.00   0.00

$ lvs -a
  LV                 VG      Attr       LSize
  lv_thin1           vg_data Vwi-a-tz-- 200.00g
  tp_data            vg_data twi-aotz--  50.00g
  [tp_data_tdata]    vg_data Twi-ao----  50.00g    # ← 实际数据卷
  [tp_data_tmeta]    vg_data ewi-ao----  4.00m     # ← 元数据卷

字段含义：

• • Attr 第 1 位 t = thin LV，T = thin pool
• • Vwi- 中 V = virtual
• • Data% = thin pool 数据占用率
• • Meta% = thin pool 元数据占用率
• • tp_data_tdata 和 tp_data_tmeta 是隐藏的内部卷

三、Thin LV 使用

3.1 格式化与挂载

thin LV 用法和普通 LV 一样：

$ mkfs.xfs /dev/vg_data/lv_thin1
$ mount /dev/vg_data/lv_thin1 /mnt/thin
$ df -h /mnt/thin
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_thin1 200G   33M  200G   1% /mnt/thin

注意 df 显示的是 虚拟大小 200G，但 pool 里实际可能只占几百 MB。

3.2 看实际占用

# 看 pool 占用
$ lvs -o lv_name,data_percent,metadata_percent vg_data
  LV       Data%  Meta%
  tp_data   1.23   0.45
  lv_thin1  1.23   0.45

# 看 thin LV 实际占用（不是虚拟大小！）
$ lvs -o lv_name,lv_size,lv_metadata_size,pool_lv vg_data

四、Thin Snapshot：传统快照的进化

4.1 创建

# thin 快照几乎瞬间，size 可以很大
$ lvcreate -s --thin -n lv_thin_snap vg_data/lv_thin1
  Logical volume "lv_thin_snap" created.

巨大优势：

• • 无需指定 snapshot area 大小
• • 不会因为满了而失效
• • 创建 N 个快照几乎瞬时

4.2 多个快照

# 创建 10 个快照都没问题
$ for i in {1..10}; do
    lvcreate -s --thin -n lv_thin_snap$i vg_data/lv_thin1
done

4.3 验证

$ lvs
  LV             VG      Attr       LSize   Pool    Origin    Data%  Meta%
  lv_thin1       vg_data Vwi-a-tz-- 200.00g tp_data             1.23   0.45
  lv_thin_snap1  vg_data Vwi-a-tz-- 200.00g tp_data   lv_thin1   0.00   0.45
  lv_thin_snap2  vg_data Vwi-a-tz-- 200.00g tp_data   lv_thin1   0.00   0.45
  ...

Data% 显示 pool 总占用，不是单个快照。

4.4 用快照做可写副本

# 创建可写快照（thin 模式）
$ lvcreate -s --thin -n lv_clone -p rw vg_data/lv_thin1

# 修改克隆不影响源
$ mkfs.xfs /dev/vg_data/lv_clone

五、Thin Pool 扩容

thin pool 满了会怎样？所有 thin LV 全部变成只读！这是最严重的故障之一。

# 扩 thin pool（必须保证 VG 里有空间）
$ lvextend -L +20G vg_data/tp_data

扩容后 thin LV 恢复正常可写。

六、删除 Thin LV 与 Pool

# 删除 thin LV
$ lvremove /dev/vg_data/lv_thin1

# 删除 thin pool（必须先删所有 thin LV）
$ lvremove /dev/vg_data/tp_data

七、Thin Pool 满了怎么办

7.1 预防：监控

# 监控脚本
$ watch -n 60 'lvs -o lv_name,data_percent,metadata_percent vg_data'

# 报警阈值：
# Data% > 80%：警告
# Data% > 95%：危险
# Meta% > 60%：危险（无法在线扩）

7.2 临时处理：删除不用的快照

# 看哪些 thin LV 占用最多
$ lvs -a -o lv_name,pool_lv,lv_size
$ lvs -o lv_name,data_percent

# 删大快照
$ lvremove /dev/vg_data/lv_thin_snap_old

7.3 永久处理：扩容 pool

# 加新 PV
$ pvcreate /dev/sde
$ vgextend vg_data /dev/sde

# 扩 pool
$ lvextend -l +100%FREE vg_data/tp_data

八、Thin LV 转普通 LV

# 把 thin pool 转成普通 LV（不需要 thin 特性时）
$ lvconvert --type thin-pool vg_data/tp_data   # 已经是 pool，此命令无效

# 真正想取消 thin 特性：备份数据 → 删除 → 重建成普通 LV

九、Thin Pool 的元数据陷阱

thin pool 的元数据卷（tp_data_tmeta）默认很小（几 MB）。但每个 thin LV 和每个 chunk 都会消耗一些元数据空间：

1000 个 thin LV + 大量快照 → 元数据卷可能撑爆

元数据满了无法在线扩容（虽然 LVM 2.03+ 支持了，但仍有风险）：

# 看元数据卷大小
$ lvs vg_data/tp_data -o lv_metadata_size,metadata_percent

# 永久办法：thin pool 元数据迁移（复杂）
# 临时办法：减少 thin LV 数量

十、Thin Provisioning 性能

thin_lvm 的写入性能损失主要在 chunk 分配阶段。如果你的场景有大量随机写，请用 预分配模式：

# 不推荐（罕见）：先预分配 chunk
# 通常接受默认按需分配即可

十一、生产环境最佳实践

1. 1. 始终监控 Data% 和 Meta%，报警阈值 80%
2. 2. thin pool 大小应该是所有 thin LV 总虚拟大小的 40~60%（避免一开始就紧张）
3. 3. 不要在 OLTP 数据库上用 thin，性能不稳定；OLTP 用普通 LV
4. 4. thin LV 上加 discard mount option：

# /etc/fstab
/dev/vg_data/lv_thin1  /mnt/thin  xfs  defaults,discard  0 0

discard 让删除文件时把空间还给 thin pool，否则空间只增不减。

1. 5. 定期 fstrim：

# 手动 trim
$ fstrim /mnt/thin

# 定时任务（每周一次）
$ cat /etc/cron.weekly/fstrim
#!/bin/bash
fstrim -a

十二、本篇小结

口诀：

• • 虚拟可超分，实际看 pool
• • Data% 监控是生命线
• • OLTP 用普通 LV，开发测试用 thin
• • 加 discard + 定期 fstrim 才能真正释放空间