无法回收LVM瘦池空间问题求助

问题背景 #

与LVM卷相比，thin pool占用量极大但实际未被充分使用。此前因元数据区域已满进行扩容后，出现LVM transaction id mismatch问题，通过vgcfgbackup→修改事务ID→vgcfgrestore的步骤解决。但执行vgcfgrestore后，瘦池空间无法回收，删除快照、对挂载卷执行fstrim均无效。

相关命令输出 #

$ lvs -a vg0 -o +discards
LV                 VG      Attr       LSize   Pool       Origin    Data%  Meta%  Move Log Cpy%Sync Convert Discards
  20221101.120002    vg0 Vwi-aotz-k  15.00t tpool0 tvol0 29.13                                               passdown
  20221101.180001    vg0 Vwi-aotz-k  15.00t tpool0 tvol0 29.13                                               passdown
  20221102.000001    vg0 Vwi-aotz-k  15.00t tpool0 tvol0 29.13                                               passdown
  20221102.060001    vg0 Vwi-aotz-k  15.00t tpool0 tvol0 29.13                                               passdown
  20221102.120001    vg0 Vwi-aotz-k  15.00t tpool0 tvol0 29.13                                               passdown
  tpool0             vg0 twi-aotz--  16.00t                          90.86  0.59                             passdown
  [tpool0_tdata]     vg0 Twi-ao----  16.00t                                                                      
  [tpool0_tmeta]     vg0 ewi-ao---- <15.01g                                                                      
  [tpool0_tmeta]     vg0 ewi-ao---- <15.01g                                                                      
  tvol0              vg0 Vwi-aotz--  15.00t tpool0                   29.13                                   passdown
  [lvol0_pmspare]    vg0 ewi------- <15.01g                                                                      
  [lvol0_pmspare]    vg0 ewi------- <15.01g                                                                      
  [lvol0_pmspare]    vg0 ewi------- <15.01g 

$ dmsetup ls | grep vg0 | sort -k2 -V
vg0-tpool0_tmeta    (253:4)
vg0-tpool0_tdata    (253:5)
vg0-tpool0-tpool    (253:6)
vg0-tpool0          (253:7)
vg0-tvol0           (253:8)
vg0-20221102.000001 (253:16)
vg0-20221102.060001 (253:17)
vg0-20221102.120001 (253:18)
vg0-20221101.120002 (253:19)
vg0-20221101.180001 (253:20)

$ grep . /sys/block/dm-{4..8}/queue/discard_max_bytes 
/sys/block/dm-4/queue/discard_max_bytes:0
/sys/block/dm-5/queue/discard_max_bytes:0
/sys/block/dm-6/queue/discard_max_bytes:0
/sys/block/dm-7/queue/discard_max_bytes:0
/sys/block/dm-8/queue/discard_max_bytes:17179869184

排查与解决思路 #

• 检查并修复元数据一致性
  先暂停所有依赖该瘦池的卷，执行元数据完整性检查：

  thin_check /dev/mapper/vg0-tpool0_tmeta
  

  若发现损坏，使用thin_repair修复：

  thin_repair -i /dev/mapper/vg0-tpool0_tmeta -o /tmp/tmeta_repaired
  vgchange -an vg0
  dd if=/tmp/tmeta_repaired of=/dev/mapper/vg0-tpool0_tmeta
  vgchange -ay vg0
  

• 手动触发瘦池空间回收
  直接调用工具强制回收空闲空间：

  thin_reclaim /dev/mapper/vg0-tpool0_tdata
  

  或通过LVM命令触发：

  lvchange --reclaim tpool0
  

• 修复discard配置
  从输出可见，元数据、数据等设备的discard_max_bytes为0，未启用TRIM支持。先确认底层存储支持TRIM，再重新配置瘦池：

  lvchange --discard=always tpool0
  

  配置后验证生效：

  grep . /sys/block/dm-{4..7}/queue/discard_max_bytes
  

• 验证快照删除后的元数据同步
  确认快照已彻底删除，刷新LVM缓存后检查使用率：

  vgscan --cache
  lvs -a vg0 -o +data_percent
  

  若仍有残留，尝试导出再导入卷组：

  vgexport vg0
  vgimport vg0
  

• 排查事务ID修复残留问题
  对比当前卷组配置与备份文件是否一致：

  vgcfgbackup -f /tmp/vg0_current vg0
  diff /path/to/your_old_backup /tmp/vg0_current
  

  若存在不一致，重新调整事务ID后再次执行vgcfgrestore，确保元数据与实际数据状态匹配。

内容的提问来源于stack exchange，提问作者PLIP