lvm扩容需先确保vg有空闲空间，再lvextend扩展lv，最后resize2fs调整ext4文件系统；缩容必须先e2fsck和resize2fs缩小文件系统，再lvreduce缩小lv；xfs不支持缩容，应避免强行操作。
扩容逻辑卷前必须先扩展底层物理空间
很多人卡在 lvextend 报错“insufficient free space”，其实不是命令写错了，而是没确认 vgdisplay 显示的 Free PE / Size 是否为正。LVM 扩容是分层操作：物理磁盘空闲 → 物理卷（PV）已纳入卷组（VG）→ 卷组有剩余空间 → 逻辑卷（LV）才能扩展。
常见疏漏点：
- 新加硬盘没执行
pvcreate /dev/sdX就直接vgextend，报错Device /dev/sdX not found - 用
fdisk分区后写了新分区表但没执行partprobe或重启，内核没识别新分区，pvcreate失败 - 误以为
lvextend -l +100%FREE能自动拉满 VG 空间，结果发现 VG 本身没空余 —— 先跑vgdisplay看一眼再动手
ext4 文件系统扩容必须分两步：LV 扩展 + 文件系统在线调整
lvextend 只改块设备大小，不碰文件系统。如果跳过 resize2fs，df -h 仍显示旧容量，且后续写入可能触发 I/O 错误。
实操要点：
- 在线扩容（ext4）：先
lvextend -L +10G /dev/vgname/lvname，再resize2fs /dev/vgname/lvname（无需卸载） - 如果 LV 已挂载在
/data，resize2fs会自动识别并扩展已挂载文件系统，但要求内核支持 online resize（2.6.10+ 基本都支持） - 别用
resize2fs /dev/vgname/lvname 20G指定绝对大小，容易算错；优先用resize2fs /dev/vgname/lvname（无参数）让它自动匹配 LV 当前大小
缩容逻辑卷是高危操作，必须严格按顺序且全程校验
缩容出问题基本等于丢数据，因为 lvreduce 会直接截断 LV 底层块，而文件系统未必知道上层被砍了。核心原则：文件系统先缩，LV 再缩，且文件系统缩的尺寸必须小于 LV 目标尺寸。
安全缩容步骤：
- 强制检查文件系统：
e2fsck -f /dev/vgname/lvname（必须，否则resize2fs拒绝缩小） - 缩小文件系统（例如缩到 15G）：
resize2fs /dev/vgname/lvname 15G（注意：这是文件系统目标大小，不是 LV 大小） - 再缩小 LV：
lvreduce -L 15G /dev/vgname/lvname（必须 ≤ 上一步的文件系统大小，否则元数据损坏） - 最后再跑一次
e2fsck校验
常见错误：lvreduce -L 15G 后立刻 mount，结果 kernel 报 bad magic number —— 因为文件系统还没缩，LV 就被硬砍了。
缩容 XFS 文件系统不支持在线缩小，必须备份重做
XFS 的设计决定它无法安全缩小已挂载或未挂载的文件系统。任何尝试用 xfs_growfs -D 或第三方工具强行缩容，都会导致不可逆损坏。
真实可行路径只有两条：
- 备份数据 →
umount→mkfs.xfs重建更小 LV → 恢复数据 - 保持原 LV 不变，用
lvs查看实际使用率，如果远低于当前大小，其实没必要缩容 —— LVM 的优势本就是“用多少划多少”，空间闲置不影响性能
很多团队踩坑在于查到 “XFS can’t be shrunk” 就放弃，却忽略了：只要没填满，XFS 在大 LV 上运行完全正常，缩容反而是引入风险的操作。
