LVM扩容必须按PV→VG→LV→文件系统顺序操作：先确认pvdisplay中Free PE>0，再用vgextend添加PV，lvextend扩大LV，最后用resize2fs或xfs_growfs同步文件系统大小。

扩容前必须确认物理卷已包含空闲空间

直接运行 lvextend 会失败，不是命令写错了，而是底层没地方可扩。先看 pvdisplay 输出里 Free PE / Size 是否大于 0；如果为 0，说明新加的磁盘还没加进卷组，或者旧 PV 已被占满。

• 新加硬盘后，必须先用 pvcreate /dev/sdX 初始化，再用 vgextend <code>vg_name /dev/sdX 加入卷组
• 如果用的是同一块盘上的新分区（如 /dev/sda3），要确保它没被格式化、没挂载、且分区类型设为 8e（Linux LVM）
• vgdisplay 的 Free PE 值才是真实可用容量单位，别只看 df -h 显示的 LV 大小

lvextend 后必须同步调整文件系统大小

很多人执行完 lvextend -l +100%FREE /dev/vg_name/lv_name 就以为完了，结果 df -h 完全没变——因为逻辑卷扩大了，但上面的 ext4/xfs 文件系统还不知道这事。

• ext4：必须跟 resize2fs /dev/vg_name/lv_name（在线执行，无需卸载）
• xfs：必须用 xfs_growfs /mount/point（注意：参数是挂载点，不是设备路径！填 /dev/... 会报错 XFS_IOC_GROWFSSIZE failed: Invalid argument）
• 别在 LV 扩容前运行文件系统调整命令，resize2fs 会拒绝处理比 LV 还大的文件系统

在线扩容是否安全？取决于文件系统和使用方式

ext4 和 xfs 都支持在线扩容（即不 umount），但“能做”不等于“没风险”。核心限制不在 LVM 层，而在上层应用是否正在大量写入或锁文件。

• 数据库类服务（如 MySQL、PostgreSQL）建议在低峰期操作，并确认其数据目录所在 LV 正在被扩容
• 如果 LV 上跑的是根分区（/），ext4 可以在线 resize，xfs 也支持，但内核版本低于 3.10 的 xfs_growfs 可能无法处理某些元数据布局
• 曾见过因 RAID 卡缓存未刷盘，导致 lvextend 返回成功但实际 PV 写入延迟，后续 resize2fs 校验失败——所以扩容前后建议跑一次 sync 并检查 dmesg 有无 I/O 报错

常见错误：df 不更新、lvscan 显示 inactive、LV 名称输错

这三个现象高频出现，原因都很具体，不是配置玄学。

• df -h 不刷新：大概率漏了文件系统调整步骤，或执行了 resize2fs 但目标设备名写成旧路径（比如用了 /dev/mapper/vg-lv 而不是 /dev/vg_name/lv_name）
• lvscan 显示 inactive：说明该 LV 没被激活，一般发生在系统重启后 VG 未自动启用，运行 vgchange -ay <code>vg_name 即可
• LV 名称输错：LVM 不校验路径是否存在，lvextend -L +10G /dev/vg_name/xxx 中 xxx 若不存在，命令仍返回成功，但实际什么都没做——务必用 lvs 确认 LV 名字拼写和所属 VG

LVM 扩容真正卡住的地方，往往不是命令记不住，而是分不清「卷组空闲空间」「逻辑卷大小」「文件系统大小」这三层边界。少查一步 pvdisplay 或漏敲一个 resize2fs，就会陷入“明明扩了却没用”的状态。