




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),说明快照已损坏或未正确激活。
调高 autoextend_percent 不是万能解。以下情况即使参数合理,快照仍可能瞬间 overflow:
dm_snapshot 内部队列溢出thin_snapshot),此时 autoextend_* 参数完全无效,必须用 lvconvert --thinpool 管理空间lvmetad 且未配置 udev 规则,导致监控线程没跑,参数形同虚设最稳妥的做法:对关键业务快照,始终预留至少 2× 预估变更量的空间,并用 lvchange --monitor y + systemd 定时检查 lvs | grep Invalid 做兜底告警。