autoextend_percent设太低会因频繁小步扩容跟不上写入速率，导致快照空间耗尽而静默失效；应协同调高threshold（70–85）、percent（50–100）并确保监控启用。
为什么 autoextend_percent 设太低会触发 snapshot overflow
LVM 快照依赖 COW（Copy-on-Write）机制，当原始 LV 数据块被修改时，旧数据先复制到快照区域。一旦快照 LV 的空间耗尽，LVM 会自动丢弃快照（snapshot is invalid），而不是暂停写入——这是静默失败，容易被忽略。
autoextend_percent 控制快照使用率到达多少百分比时触发自动扩容。默认值通常是 100（即不自动扩），但若设为 50 或更低，而实际 I/O 模式又偏随机、写密集（比如数据库日志刷盘、rsync 同步大文件），就会频繁触发扩容；但扩容本身有延迟，且依赖 autoextend_threshold 和剩余 VG 空间。若阈值过低 + 扩容间隔短 + VG 空间不足，反而加速 overflow。
- 典型错误现象：
lvscan显示快照状态为Invalid，dmesg里出现snapshot: Exception table full - 根本原因不是“空间不够”，而是“来不及扩”——
autoextend_percent太小导致扩容太激进，但每次只扩一点（如 128M），跟不上写入速率 - 该参数仅对启用了
snapshot_autoextend_threshold和snapshot_autoextend_percent的逻辑卷生效，且需lvchange --monitor y开启监控
如何安全调高 autoextend_percent 并配平其他参数
目标是让扩容更“懒”但更“稳”：减少触发频次，单次扩容量足够覆盖后续一段写入压力。关键不是孤立改一个值，而是协同调整三个参数：
-
snapshot_autoextend_threshold：快照使用率（%）达到该值才检查是否扩容，默认 100；建议设为 70–85（留出缓冲窗口） -
snapshot_autoextend_percent：每次扩容增加原大小的百分比，默认 20；若原快照只有 1G，20% 就只加 200M，太小；建议设为 50–100（即翻倍或更多） -
lvm.conf中的snapshot_reserve：预留空间比例（默认 20%），影响首次创建快照时分配大小，和 autoextend 无关，但会影响起点容量
实操命令示例（以快照 vg00/snap_db 为例）：
lvchange --snapshot-autoextend-threshold 80 \
--snapshot-autoextend-percent 80 \
vg00/snap_db
注意：修改后需确保 lvmetad 或 udev 规则已启用监控，否则参数不生效；可运行 lvchange --monitor y vg00/snap_db 显式开启。
检查当前配置与实时使用率的实用命令
别只看 lvs 输出的 sn% 列——那是瞬时快照块占用率，不含预留或未提交的 COW 请求。真正要盯的是：
-
lvs -o+snapshot_autoextend_threshold,snapshot_autoextend_percent,monitor vg00/snap_db：确认参数已加载 -
dmsetup status /dev/mapper/vg00-snap_db：输出类似0 2097152 snapshot 8388608 4096/10485760，最后两数表示已用/总快照块数，可换算真实使用率 -
lvs --options +data_percent,metadata_percent vg00/snap_db：部分新内核支持显示元数据区压力，元数据满也会导致 invalid
如果 dmsetup status 显示分母远小于你预期的快照大小（比如你设了 2G 快照，但分母只有 1M 块 × 4K = 4G？不对——注意单位是扇区，需除以 2048 得 MB），说明快照已损坏或未正确激活。
扩容后仍 overflow 的几个隐蔽原因
调高 autoextend_percent 不是万能解。以下情况即使参数合理，快照仍可能瞬间 overflow：
- 底层存储响应慢（如 NFS backend、高延迟 SSD），COW 提交延迟累积，
dm_snapshot内部队列溢出 - 快照 LV 本身在 thin pool 上（
thin_snapshot），此时autoextend_*参数完全无效，必须用lvconvert --thinpool管理空间 - 系统禁用了
lvmetad且未配置 udev 规则，导致监控线程没跑，参数形同虚设 - 内核版本 snapshot target 的竞态 bug，偶发丢块而不报错
最稳妥的做法：对关键业务快照，始终预留至少 2× 预估变更量的空间，并用 lvchange --monitor y + systemd 定时检查 lvs | grep Invalid 做兜底告警。
