LV大小是逻辑上限，不反映实际数据量；PE是物理分配最小单元，默认4MB；扩容必须先lvextend再扩展文件系统，顺序不可颠倒。
Linux 存储卷的逻辑空间分配和物理空间占用不是一回事，它们分属不同层级：逻辑空间是上层应用看到的“可用容量”，物理空间是底层磁盘实际消耗的“真实字节”。理解两者差异，才能避免误判空间不足或扩容失效。
逻辑卷（LV）大小 ≠ 文件系统已用空间
创建一个 10GB 的逻辑卷（如 lvcreate -L 10G -n lv_data vg0），只是在 VG 中预留了 10GB 的 LE（逻辑块）资源，并不意味着文件系统立刻占满这 10GB。此时：
- LV 设备节点（如
/dev/vg0/lv_data）显示大小为 10GB； - 挂载后执行
df -h，可能只显示几百 MB 已用——因为实际写入的数据远少于 LV 容量； - LV 本身不记录“文件级使用率”，它只提供一块连续/非连续的块设备空间。
换句话说：LV 是“容器”，不是“内容”。它的大小决定上限，但不反映当前数据量。
物理卷（PV）与卷组（VG）的 PE 分配才是真实占用
所有 LV 的空间最终来自 PV 上划分的 PE（物理块）。PE 大小默认为 4MB（可创建 VG 时指定），且一旦设定不可更改。关键点在于：
- 每个 LV 占用的 PE 数 = LV 大小 ÷ PE 大小（向上取整）；
- 这些 PE 在 PV 上可能分散分布，但必须全部被分配出去才计入 VG 的已用空间；
-
vgdisplay显示的 Free PE / Size 是真正可用于新建或扩容 LV 的物理资源； - 即使 LV 被格式化为 XFS 或 ext4 并挂载，只要没写满，其底层 PE 仍被 VG 锁定、不可被其他 LV 复用。
例如：VG 总共 2000 个 PE（8GB），已分配 1500 个给两个 LV，则剩余 500 个 PE（2GB）就是当前物理层面的可用余量。
文件系统扩容不等于 LV 扩容，顺序不能颠倒
当需要增大挂载目录的可用空间时，常见错误是只运行 xfs_growfs 或 resize2fs，却忘了先扩展 LV。正确路径是单向依赖：
- 必须先用
lvextend增大 LV 容量（即分配更多 PE）； - 再用
xfs_growfs /mount/point（XFS）或resize2fs /dev/vg0/lv_data（ext4）让文件系统识别并管理新增块设备空间； - 若跳过第一步，
df -h将完全看不到容量变化，因为文件系统无法使用尚未分配的底层存储。
反向操作（先扩文件系统再扩 LV）无效，且无意义——文件系统只能使用 LV 当前暴露的设备大小。
碎片与未分配空间：VG 中的“闲置资源”
一个 VG 可能有大量 Free PE，但仍然无法扩容某个 LV，原因常有两个：
-
LV 所在 VG 已无 Free PE：此时需先添加新 PV（
pvcreate + vgextend）； -
LV 本身设置了最大逻辑边界（如
lvchange --maxlogicalvolumes），但更常见的是：该 LV 所属 VG 虽有空闲 PE，但文件系统类型不支持在线扩容（如 ext2 不支持resize2fs在挂载状态下扩大）； - 注意：
lsblk中 TYPE 列显示为lvm才表示该设备走 LVM 路径；若显示part或disk，说明未启用 LVM，扩容只能靠传统分区工具，风险高且不可逆。
真正的弹性，始于投产时就采用 LVM 架构——它把物理碎片转化成逻辑连续，把硬件限制变成软件策略。
