LVM快照采用写时复制（CoW）机制，创建瞬间几乎不占空间，仅随原卷数据修改而增长；超限时变为invalid，需及时删除或优化预留策略。
Linux 中 LVM 快照本身不“占用”额外空间，而是随着原卷（origin）数据被修改，不断记录变化块（COW，Copy-on-Write），导致快照逻辑卷（snapshot LV）持续增长。一旦快照卷写满，它会自动变为 invalid 状态，后续读取将失败，甚至可能影响原卷稳定性。所以“清理快照占用空间”的核心不是“清空快照”，而是及时释放不再需要的快照，或控制其增长行为。
一、确认快照状态与实际占用
快照空间是否真的告急，得先看真实情况：
- 运行
lvs -o +snap_percent,origin，查看所有逻辑卷中哪些是快照（Attr列含s），重点关注Snap%列——超过 80% 就该警惕，100% 表示已失效； - 用
lvdisplay /dev/vgname/snapshot_lvname查看Allocated to snapshot和Current snapshot size，确认当前已分配空间； - 注意：快照卷大小在创建时指定（如
lvcreate -s -L 2G ...），它不会自动扩容，超限即停。
二、安全删除无用快照
如果快照只是临时用于备份、测试或升级验证，且已完成目的，应立即删除：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 确保没有进程正在读取该快照（如挂载使用、rsync 源、dd 读取等），可用
lsof /mount/point或findmnt | grep snapshot_lvname检查； - 若已挂载，先
umount /mount/point； - 执行
lvremove /dev/vgname/snapshot_lvname，输入y确认； - 删除后，原卷不受影响，所占 PE 空间立即归还给卷组（
vgs可见VFree增加）。
三、避免快照失控的实操建议
与其事后“清理”，不如从源头控住增长：
- 设合理初始大小：快照大小不是越大越好，但也不能太小。经验法则是按原卷预计变更量预估——例如数据库快照，可参考日均 binlog 增长 + 缓存刷盘频率，预留 5–10% 原卷大小起步；
-
禁用自动激活（慎用）：默认快照随 VG 启动而激活，易被遗忘。可在创建时加
--setactivationskip y，需手动lvchange -ay才启用； -
监控 + 自动清理：在运维脚本中加入检查，例如：
lvs --noheadings -o snap_percent,lv_name,vg_name | awk '$1 > 90 {print "ALERT: "$2" in "$3" at "$1"%"}'，配合定时任务触发告警或自动删除过期快照； - 优先用 thin pool 快照（推荐升级）：传统 LVM 快照是 COW，而 thin-provisioned LV 的快照是 redirect-on-write（ROW），更节省空间、支持多层快照、可动态扩容。若环境允许，迁移到 thin pool 是长期更优解。
四、快照已 invalid 怎么办？
当 lvs 显示 Invalid 或 snapshot_invalid，说明快照元数据损坏或空间耗尽，无法恢复。此时唯一安全做法是：
- 立即停止对该快照的任何访问；
- 运行
lvconvert --repair /dev/vgname/snapshot_lvname尝试修复（成功率低，仅适用于轻微元数据异常）； - 绝大多数情况下，直接
lvremove删除即可——原卷数据完全不受影响，这是 LVM 快照设计的安全保障。
