LVM 的基本结构与常用命令

每次要给服务器增加存储空间，流程都差不多：打开搜索框，敲下 lvcreate 参数 或 lvextend 用法，翻两篇博客，找一条接近当前场景的命令。操作完成，页面一关，下次再遇到，还是得重新查。

我之前写过一篇《Linux 在线扩容完全指南》。这次换个角度：先弄清楚 LVM 管理的对象，以及这些对象之间的关系，再回头看命令为什么这样写。

查手册当然有用，只是缺少整体认识时，man lvcreate 里几十个选项很容易把人绕晕。-L 和 -l 只差一个大小写，背下来不难，却很难记住它们为什么不同、什么时候该用哪一个。

记命令时，可以先拆开看：lvcreate 是创建 LV，vgextend 是扩展 VG。前缀指明操作对象，后半部分指明动作；需要分配空间时，再用参数说明大小。容易混淆的地方，往往是没分清操作对象，或者不知道容量按什么单位计算。

下面先看结构，再看空间怎样分配，最后把它们对应到命令上。涉及映射与容量计算时，先以最常见的普通线性 LV 为例。

一、先分清三层：空间从哪来，归谁管，交给谁用

假设服务器上有两块磁盘 /dev/sdb 和 /dev/sdc，现在需要从中划出一部分空间，给应用存放数据。LVM 把这个过程分成三层：先把设备纳入管理，再汇集空间，最后按需分配。

PV（Physical Volume，物理卷）是底层的空间来源。 执行 pvcreate 后，两块磁盘分别成为两个 PV。每个 PV 仍对应自己的底层设备。初始化让 LVM 能识别设备；加入 VG 后，其中的空间才参与逻辑卷的分配。

VG（Volume Group，卷组）把这些 PV 的空间汇集起来，统一分配。 例如，把这两个 PV 加入 vg_data，就建立了一个由两块设备共同提供容量的存储池。此后创建逻辑卷时，可以从这个池中申请空间，不必事先把容量限定在某一块磁盘上。不过，VG 有自己的边界：属于另一个 VG 的空闲空间，不能直接拿来使用。

LV（Logical Volume，逻辑卷）是从这个池中划出的可用设备。 例如，从 vg_data 中分配 50 GiB，创建 lv_app，系统就会得到 /dev/vg_data/lv_app 这个块设备。它的底层空间可以来自一个 PV，也可以分布在两个 PV 上；应用使用时，看到的仍是同一个逻辑设备。

因此，从下往上看，PV 提供空间，VG 汇集空间，LV 按需取得空间。文件系统建在 LV 上，再挂载到目录供应用访问。

这里的 PV 不一定是一整块硬盘，也可以是分区、软 RAID 或加密映射等块设备。“物理卷”描述的是它作为底层空间来源的角色，不要求它与一块真实硬盘一一对应。

这里有个帮助记忆的小技巧：先记住 PV，P 是 Physical（物理）的首字母，所以从底层设备开始。再看共同的字母 V：它在 PV 的末尾，到了 VG 的开头，最后又回到 LV 的末尾。按 PV → VG → LV 串起来，就是物理卷提供空间、卷组汇集空间、逻辑卷取得空间。

把这三层关系画出来，就得到下面这张图。先沿箭头从下往上看：底层设备初始化为 PV，多个 PV 加入同一个 VG，再从 VG 中分配空间创建 LV，最后在 LV 上建立文件系统并挂载。

图中的 /dev/md0 具体表示 md 软 RAID 设备；多路径和 LUKS 映射是另外两类可作为 PV 使用的块设备，并非都使用这个路径。/dev/loop0 表示由文件提供存储空间的 loop 块设备。

图中的两个 LV 都使用了多个 PV 上的空间，但这些 PV 属于同一个 VG。LV 可以跨 PV，不能跨 VG。 三者的归属关系如下：

PV 是空间来源：加入 VG，为它提供可分配空间。

VG 是管理与分配的边界：管理哪些 PV，以及空间分给哪些 LV。

LV 是分配结果：从所属 VG 中取得空间，对上层提供逻辑设备。

再看LVM三层抽象图中的 lv_app：它使用了一部分蓝色空间和一部分绿色空间，分别来自两个 PV。图中的小方块表示分配单位；这些单位有多大，怎样对应到 LV，下面用 PE 和 LE 说明。

二、空间分配的单位：PE 与 LE

LVM 分配空间时，会把可用空间按固定大小划成一段一段，每一段叫作一个 extent（区段）。例如，大小设为 4 MiB，分配空间时就以 4 MiB 为一个单位。

在 PV 上，这些单位称为 PE（Physical Extent，物理区段）。PV 加入 VG 后，按照 VG 规定的大小划分 PE，因此同一个 VG 中，各 PV 的 PE 大小一致。默认大小为 4 MiB，也可以在创建 VG 时通过 vgcreate -s 指定。这里的划分由 LVM 记录和管理，不需要为每个 PE 单独创建磁盘分区。

在 LV 中，用来计算逻辑空间的单位称为 LE（Logical Extent，逻辑区段），它与所属 VG 的 PE 大小相同。对于普通线性 LV，每个 LE 对应一个 PE，实际数据保存在对应的 PE 中。

假设每个 LE 是 4 MiB，那么 1 个 LE 提供 4 MiB 的逻辑空间，100 个 LE 就提供 400 MiB。把所有 LE 的大小加起来，就是 LV 的逻辑容量：

LV 容量 = LE 个数 × 每个 LE 的大小

由于 LE 和 PE 大小相同，计算时也可以使用 VG 规定的 PE 大小。

上面的公式计算的是 LV 对外提供的逻辑容量。它实际占用多少底层空间，还要看数据怎样保存。

普通线性 LV 的每个 LE 对应一个 PE；如果采用双副本 RAID1，同一份数据需要保存两份，还要额外占用一些空间记录 RAID 元数据。下面用两种布局作对比。

上半图中，7 个 LE 对应两个 PV 上的 7 个 PE。如果每个区段为 4 MiB，LV 的逻辑容量和占用的 PE 容量都是 28 MiB。下半图中，LV 只有 4 个 LE，逻辑容量为 16 MiB，在每份 RAID 元数据占用 1 个 PE 的图示条件下，两份数据加上元数据共占用 10 个 PE，也就是 40 MiB。因此，计算 LV 容量时看 LE 数量，计算底层空间消耗时，还要考虑副本和元数据。

图中的 RAID1 特指双副本。每侧的灰色 rmeta 与数据部分 rimage 是两个独立的内部 LV；灰色块不属于 rimage，下方编号表示数据子卷内部的位置。这个例子用于比较容量开销，不表示所有 RAID1 都只有两份数据。

理解了 LE 的大小和数量，lvcreate 中两个容易混淆的参数就好区分了：

-L（--size）按容量指定大小，-l（--extents）按 LE 个数或百分比指定大小。 记住 size 是“大小”，extents 是“区段”，就容易区分两种写法。短选项容易混淆时，也可以直接使用长选项。

假设 vg_data 的 PE 大小为 4 MiB，那么其中每个 LE 也是 4 MiB。下面两条命令分别创建两个线性 LV，假设 VG 中有足够空闲空间，且示例 LV 名尚未使用：

1 2	lvcreate -L 10M -n lv_small vg_data lvcreate -l 100 -n lv_count vg_data

第一条要求创建一个 10 MiB 的 LV。但每个 LE 是 4 MiB，2 个不够，必须分配 3 个，所以实际容量是 12 MiB。

第二条直接指定 100 个 LE，容量就是 100 × 4 MiB = 400 MiB。两种参数最终都会落实到 LE 的数量上，只是指定大小的方式不同。

这些算例说明了容量怎样由 LE 数量得出。下面再看实际系统的输出，核对 PV 提供了多少 PE、VG 还剩多少空间，以及 LV 的容量如何计算。

三、通过命令输出理解 PV、VG 和 LV

下面的实际环境使用 ubuntu-vg/ubuntu-lv，与前面的 vg_data/lv_app 示意名称不同。本章只查看状态，不执行存储变更。

1. `pvdisplay`：查看 PV 的空间分配

pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               ubuntu-vg
  PV Size               <78.00 GiB / not usable 0   
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              19967
  Free PE               0
  Allocated PE          19967
  PV UUID               S5GdgS-a3Fh-xOB6-ZR9z-p3NQ-Bcqu-xP9cR1

关键字段	实际值	含义
`PV Name`	`/dev/sda3`	作为 PV 使用的磁盘分区
`VG Name`	`ubuntu-vg`	这个 PV 所属的 VG
`PE Size`	`4.00 MiB`	每个 PE 的大小
`Total PE`	`19967`	可供分配的 PE 总数
`Allocated PE`	`19967`	已分配的 PE 数量
`Free PE`	`0`	尚未分配的 PE 数量

这里可以直接计算 PV 提供的可分配容量：

1 2	19967 × 4 MiB = 79868 MiB 79868 ÷ 1024 = 77.99609375 GiB

这个结果略小于 78 GiB，对应输出中的 <78.00 GiB。

Allocatable yes (but full) 表示这个 PV 允许分配空间，但目前所有 PE 都已分配。这不代表文件系统已经写满，只代表这个 PV 没有剩余 PE 可以继续分配。

2. `vgdisplay`：查看 VG 的总量与空闲空间

vgdisplay 
  --- Volume group ---
  VG Name               ubuntu-vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <78.00 GiB
  PE Size               4.00 MiB
  Total PE              19967
  Alloc PE / Size       19967 / <78.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               CfzNJ7-24dh-42U6-IjwV-DHOC-6PLF-LIzo59

PV 提供的空间加入 VG 后，由 VG 统一管理。下面看 ubuntu-vg 包含哪些对象，以及空间的分配情况：

关键字段	实际值	含义
`VG Name`	`ubuntu-vg`	卷组名称
`Cur PV`	`1`	当前包含 1 个 PV
`Act PV`	`1`	当前有 1 个活动 PV
`Cur LV`	`1`	当前包含 1 个 LV
`PE Size`	`4.00 MiB`	卷组统一使用的 PE 大小
`Total PE`	`19967`	卷组中所有 PV 提供的 PE 总数
`VG Size`	`<78.00 GiB`	卷组的总容量
`Alloc PE / Size`	`19967 / <78.00 GiB`	已分配的 PE 数量及容量
`Free PE / Size`	`0 / 0`	尚未分配的 PE 数量及容量

结合前面的 pvdisplay，可以确认：ubuntu-vg 只有一个 PV，就是 /dev/sda3。因此，VG 的 PE 总数与该 PV 的 PE 总数相同，都是 19967。

这些 PE 已全部分配，VG 中没有剩余空间可以直接用于创建普通 LV 或扩展现有普通 LV。这里的“没有剩余空间”仍然指 VG 中没有空闲 PE，不代表 LV 上的文件系统已经写满。

3. `lvdisplay`：通过 LE 数量计算逻辑卷容量

前面确认了 ubuntu-vg 中只有一个 LV。下面查看它的归属、状态和容量：

lvdisplay 
  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/ubuntu-lv
  LV Name                ubuntu-lv
  VG Name                ubuntu-vg
  LV UUID                MOxbIB-nWOD-EjDM-HOfR-k1fF-QB4c-G6KA9x
  LV Write Access        read/write
  LV Creation host, time ubuntu-server, 2026-07-04 14:38:22 +0000
  LV Status              available
  # open                 1
  LV Size                <78.00 GiB
  Current LE             19967
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

关键字段	实际值	含义
`LV Path`	`/dev/ubuntu-vg/ubuntu-lv`	逻辑卷的设备路径
`LV Name`	`ubuntu-lv`	逻辑卷名称
`VG Name`	`ubuntu-vg`	逻辑卷所属的 VG
`LV Write Access`	`read/write`	允许读写
`LV Status`	`available`	逻辑卷已激活，可供使用
`LV Size`	`<78.00 GiB`	对上层提供的逻辑容量
`Current LE`	`19967`	逻辑卷包含的 LE 数量
`Segments`	`1`	当前由一个映射段组成

容量计算重点看 Current LE。它表示 ubuntu-lv 包含 19967 个 LE。虽然输出没有单独列出 LE 大小，但 LE 与所属 VG 的 PE 大小相同。前面的 vgdisplay 已经给出 PE 大小为 4 MiB，因此：

LV 容量 = LE 个数 × LE 大小
        = 19967 × 4 MiB
        = 79868 MiB
        = 77.99609375 GiB

结果略小于 78 GiB，与 LV Size <78.00 GiB 一致。

把三份输出放在一起，就能对应起来：/dev/sda3 提供 19967 个 PE，ubuntu-vg 统一管理这些空间，ubuntu-lv 则包含 19967 个 LE，对上层提供约 78 GiB 的逻辑容量。

4. `df -Th`：查看文件系统的使用情况

这里看到的仍然是逻辑卷容量。文件系统实际用了多少、还剩多少，需要通过 df -Th 查看。-T 显示文件系统类型，-h 使用便于阅读的容量单位；与 df -hT 的含义相同。

df -Th
Filesystem                        Type   Size  Used Avail Use% Mounted on
tmpfs                             tmpfs  775M  1.2M  774M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv ext4    77G  8.7G   64G  12% /
tmpfs                             tmpfs  3.8G     0  3.8G   0% /dev/shm
tmpfs                             tmpfs  5.0M     0  5.0M   0% /run/lock
/dev/sda2                         ext4   2.0G  251M  1.6G  14% /boot
tmpfs                             tmpfs  775M  4.0K  775M   1% /run/user/0

其中，/dev/mapper/ubuntu--vg-ubuntu--lv 与 /dev/ubuntu-vg/ubuntu-lv 指向同一个逻辑卷。与本例有关的是挂载在 / 的这一行：

关键字段	实际值	含义
`Type`	`ext4`	文件系统类型
`Size`	`77G`	文件系统报告的总容量
`Used`	`8.7G`	已使用的空间
`Avail`	`64G`	普通用户可用的剩余空间
`Use%`	`12%`	文件系统报告的空间使用率
`Mounted on`	`/`	挂载在根目录

VG 的 Free PE = 0 表示空间已经分配给 LV；文件系统的 Avail = 64G 表示这些已分配空间中，还有可供文件使用的容量。继续存放文件与继续扩大 LV，是两个不同层次的问题。

df 报告的是文件系统容量，不能直接与 LV 容量视为同一个数。文件系统开销、ext4 的保留空间以及显示时的取整，也意味着不能用这一行的近似值要求 Size = Used + Avail。

通过这四组输出，我们已经知道空间属于谁、分配了多少、文件系统用了多少。下一节继续看数据的位置：LV 中的 LE，具体对应 PV 上哪些 PE。

四、LE 到 PE 的映射与 LV 扩容

对于普通线性 LV，LVM 通过 LE 与 PE 的对应关系找到这些位置。可以把它理解成一张映射表：一边是 LV 中的 LE 编号，另一边是对应的 PV 和 PE 编号。

下面另用一组独立的示意编号展示这种关系，不与前面的图或实际设备逐项对应。阅读时，先看 LV 中连续排列的 LE，再看它们分别对应哪些 PV 上的 PE。

LV 对上层提供一段连续的逻辑地址空间，LE 从 0 开始连续编号。与之对应的 PE 不必连续，也不必全部位于同一个 PV 上。例如，前一段 LE 可以使用 /dev/sdb 上的空间，后一段使用同一 VG 中 /dev/sdc 上的空间。

每个 PV 的 PE 都独立编号。因此，只知道“PE 5”还不能确定位置，还必须知道它属于哪个 PV。图中“不连续”表示 PE 编号不必相邻；实际分配仍受 VG 范围、空闲情况和分配策略限制。

文件系统按 LV 的逻辑地址读写，由底层映射决定实际访问哪个位置。扩容时，LVM 可以保留原有映射，再为新增的逻辑地址分配底层空间。

如果想核对实际系统中的映射，可以执行 lvdisplay -m /dev/ubuntu-vg/ubuntu-lv。下面只保留输出中的映射部分：

--- Segments ---
Logical extents 0 to 19966:
  Type                linear
  Physical volume     /dev/sda3
  Physical extents    0 to 19966

这段输出表明，ubuntu-lv 是线性 LV，LE 0～19966 对应 /dev/sda3 上的 PE 0～19966，总共 19967 个。这里既验证了前一章的数量，也确定了数据所在的 PV。与上图的跨 PV 示例不同，这个实际 LV 的空间全部位于同一个 PV 上。

lvdisplay -m 只需在核对布局时使用，不必专门记忆。下面看扩容怎样在原有映射之后增加空间。

扩容：在 LV 末尾增加空间

执行 lvextend 时，LVM 为普通线性 LV 分配更多 PE，并将新增的 LE 接到原有逻辑地址范围之后。原有 LE 与 PE 的对应关系可以保留，已有数据不必整体搬家。

下面换回示例环境 vg_data/lv_app，假设它是普通线性 LV，VG 中至少有 20 GiB 可分配的空闲空间。前一章的 ubuntu-vg 已经没有空闲 PE，不能直接套用这一步。

给 lv_app 增加 20 GiB：

1	lvextend -L +20G /dev/vg_data/lv_app

其中，+20G 表示在现有容量上增加 20 GiB。

此时变大的是 LV，文件系统还需要扩展，才能使用新增空间。如果 LV 上使用 XFS，且已经挂载在 /data，继续执行：

1	xfs_growfs /data

如果该 LV 实际使用的是 ext4，则将上面的 XFS 命令换成下面这一条，两种文件系统命令按实际类型选择：

1	resize2fs /dev/vg_data/lv_app

这与上一章区分的两个层次一致：LVM 负责给逻辑卷增加空间，文件系统负责把新增空间纳入自己的管理。在工具和文件系统支持的情况下，也可以使用 lvextend -r 联动完成这两步。完成后仍应检查 LV 与文件系统容量，确认两层都已扩展。

如果 VG 中没有足够的空闲 PE，就需要先解决空间来源，再执行 lvextend。下一节以加入新盘为例说明。

五、VG 空间不足时，如何加入新盘扩容

上一节的扩容操作有一个前提：VG 中有足够的空闲 PE。若像前面实际输出中的 ubuntu-vg 一样，Free PE 已经为 0，本例选择通过加入新盘增加 VG 的可用空间。

这里要区分空间属于哪里。新盘上尚未纳入 LVM 管理的空间，或另一个 VG 中的空闲空间，都不能直接分配给当前 LV。扩展 LV 时，LVM 只能从它所属的 VG 中分配空间。

下面以加入一块新盘为例，继续使用上一节的 vg_data/lv_app。假设 /dev/sdd 是已经确认可以初始化的空盘，容量足以满足本次扩容。本节展示 VG 原本没有足够空间时的一次完整扩容；两节中的 lvextend 是同一操作的不同场景，不应连续执行两次。涉及存储变更的命令需要管理员权限，执行前按实际环境核对设备名。

1. 将新盘初始化为 PV

1	pvcreate /dev/sdd

这一步让 LVM 能够识别和管理新盘，但它还没有加入 vg_data，因此其中的空间暂时不能分配给 lv_app。

2. 将 PV 加入现有 VG

1	vgextend vg_data /dev/sdd

加入后，新 PV 的可用空间按 vg_data 的 PE 大小参与分配，VG 的总容量和空闲容量随之增加。

可以查看卷组的变化：

1	vgdisplay vg_data

重点关注 Cur PV、Total PE 和 Free PE / Size，确认新 PV 已加入，并且有足够的空闲空间。

3. 将新增空间分配给 LV

1	lvextend -L +20G /dev/vg_data/lv_app

这一步从 VG 中分配空间，为 lv_app 增加 20 GiB。执行后，LV 容量增大，VG 中的空闲 PE 数量相应减少。

如果 LV 上有文件系统，还要继续扩展文件系统。例如，沿用上一节挂载在 /data 的 XFS：

1	xfs_growfs /data

最后查看文件系统容量：

1	df -hT /data

这几步分别处理不同层次：pvcreate 初始化设备，vgextend 增加卷组空间，lvextend 增加逻辑卷容量，最后由文件系统工具使新增容量可用。

同样叫“扩容”，vgextend 和 lvextend 改变的对象并不相同。理解这些区别后，就可以进一步整理常用命令：先判断要操作 PV、VG 还是 LV，再选择相应的动作和参数。

六、最后看命令：对象加动作，参数说明空间

把前面涉及的操作按 PV、VG、LV 排开，就能看到“对象前缀 + 动作”的命名规律：

动作	PV 层	VG 层	LV 层
创建	`pvcreate`	`vgcreate`	`lvcreate`
删除	`pvremove`	`vgremove`	`lvremove`
简要查看	`pvs`	`vgs`	`lvs`
详细查看	`pvdisplay`	`vgdisplay`	`lvdisplay`
扩大	`pvresize`	`vgextend`	`lvextend`

表里动作相近，改变的对象却不同。vgextend 向 VG 加入 PV，lvextend 增加 LV 的容量；pvresize 用于调整 LVM 记录的 PV 大小，常见于底层磁盘或分区扩容之后，它本身不会扩大底层设备。如果 PV 建在分区上，必须先让该分区覆盖新增容量，再执行 pvresize；仅扩大磁盘并不等于分区也已扩大。

创建普通 LV 时，最常用的是三个选项：

选项	含义	例子
`-L` / `--size`	按容量指定大小	`-L 50G`
`-l` / `--extents`	按 LE 个数或百分比指定大小	`-l 100`、`-l 100%FREE`
`-n` / `--name`	指定 LV 名称	`-n lv_app`

-L 的输入单位按二进制解释，M、G、T 分别表示 MiB、GiB、TiB，大小写均可；不写单位时默认 MiB。-L 和 -l 是指定容量的两种方式，选择一种即可。

百分比表达式回答的是“以什么为基准来分配”：

表达式	基准
`%FREE`	VG 中剩余的空闲空间
`%VG`	VG 总容量
`%PVS`	命令中指定的 PV 上的空闲空间

普通 LV 的创建命令通常写成 lvcreate -L 50G -n lv_app vg_data。如果还要限制使用哪些 PV，可以在 VG 名之后继续列出 PV，因此 VG 名并不总是最后一个参数。

扩容时还要留意 +。lvextend -L 50G 表示把总容量扩展到 50 GiB，lvextend -L +50G 表示在现有基础上增加 50 GiB。类似地，lvextend -l +100%FREE 表示把 VG 当前剩余的空闲空间全部追加给这个 LV。

前面示例针对已有 LV 扩容。下面另外给出从空盘创建 VG、LV 和文件系统的流程，不要接在扩容操作后执行。这里用两块盘创建一个 VG，从中分配 50 GiB 给 LV，再创建文件系统并挂载。示例假设 /dev/sdb、/dev/sdc 是确认可初始化的空盘，有足够容量，且 /data 是准备使用的挂载目录；pvcreate 与 mkfs 不应直接用于需要保留数据的设备。

pvcreate /dev/sdb /dev/sdc                  # 初始化两个 PV
vgcreate -s 4M vg_data /dev/sdb /dev/sdc    # 组建 VG，指定 extent 大小
lvcreate -L 50G -n lv_app vg_data           # 从 VG 分配空间，创建 LV
mkfs.xfs /dev/vg_data/lv_app                # 在 LV 上创建文件系统
mkdir -p /data
mount /dev/vg_data/lv_app /data             # 挂载到目录

这个例子把三层初始化分开写，是为了看清每一步的职责；实际使用中，vgcreate 也能初始化尚未创建为 PV 的设备。这里的 mount 仅完成当前挂载；如需开机自动挂载，还要按文件系统 UUID 配置 /etc/fstab。

需要查参数时，先用 --help 看命令形态，再用 man 查选项含义与限制。lvcreate 支持多种 LV 类型，阅读帮助时应找到当前类型对应的用法，不必一次看完所有分支，也不要默认第一种用法就适合当前任务。

小结：日常查看与扩容速查

以下面向普通线性 LV 上的 ext4、XFS 文件系统。先查看实际设备、VG、LV 和挂载点，再选择对应场景。示例中的设备名需要替换为现场值，存储变更命令以 root 或通过 sudo 执行。

1. 先查哪一层缺空间

目的	命令	重点查看
查看磁盘和分区容量	`lsblk`	磁盘、分区、LV 的层级及大小
查看文件系统类型和剩余容量	`df -hT`	`Type`、`Avail`、挂载点
查看 PV 归属和空闲容量	`pvs`	`PV`、`VG`、`PSize`、`PFree`
查看 VG 是否还能分配空间	`vgs`	`VSize`、`VFree`
查看 LV 容量	`lvs`	`LV`、`VG`、`LSize`
查看 PE、LE 的详细数量	`pvdisplay`、`vgdisplay`、`lvdisplay`	`PE Size`、`Free PE`、`Current LE`

df 的空闲空间供文件系统使用；vgs 的 VFree 才是 VG 尚未分配给 LV 的空间。两者不能混用。

2. 按场景准备 VG 空间

下面两种准备方式按实际情况选择；若 VG 已有足够空闲空间，直接跳到第 3 步。

加入一块新盘： 确认 /dev/sdd 是可以初始化的空盘，再执行：

1
2
3

pvcreate /dev/sdd
vgextend ubuntu-vg /dev/sdd
vgs ubuntu-vg

pvcreate 仅用于准备新的 PV，不要在已有数据的 PV 上重新执行。

原有 PV 的底层设备已经扩容： 先通过 lsblk 确认系统识别了新增容量。如果 PV 位于分区上，先完成分区扩展并确认内核识别了新大小；然后让 LVM 使用新增空间：

1
2
3

# 仅在 /dev/sda3 分区本身已经扩容后执行
pvresize /dev/sda3
vgs ubuntu-vg

这种情况下 PV 已经属于 VG，不需要再次执行 pvcreate 或 vgextend。磁盘、分区的扩展方法取决于环境，这里不提供通用分区修改命令。

3. 扩展 LV

确认目标 VG 的空闲容量至少为 20 GiB 后，给其中一个已有的普通线性 LV 增加 20 GiB：

1	lvextend -L +20G /dev/ubuntu-vg/ubuntu-lv

本速查统一使用前文的 ubuntu-vg/ubuntu-lv；其他环境需替换为实际 VG 和 LV 名称。

写法	含义
`-L +20G`	在现有容量上增加 20 GiB
`-L 100G`	将总容量扩展到 100 GiB，目标必须大于当前容量
`-l +100%FREE`	将 VG 当前可分配的空闲空间全部追加给该线性 LV，不再为其他 LV 留余量

这些写法选一种即可，不是要依次执行的步骤。

4. 扩展文件系统并检查结果

先确认文件系统类型和挂载点，再选择一条对应命令：

文件系统	命令示例	参数
ext4	`resize2fs /dev/ubuntu-vg/ubuntu-lv`	LV 设备路径
已挂载的 XFS	`xfs_growfs /data`	文件系统挂载点

前文的实际环境是 ext4，选择 resize2fs 这一行即可。XFS 一行仅说明另一种文件系统的用法，/data 必须换成它的实际挂载点。扩容已有文件系统不需要重新执行 mkfs。

工具和文件系统支持时，也可以用 lvextend -r -L +20G /dev/ubuntu-vg/ubuntu-lv 联动扩容，替代第 3 步及手动扩展文件系统；不要在已经成功增加 20 GiB 后再重复执行这条命令。

最后检查：

1
2
3

lvs
vgs
df -hT

确认 LV 容量和目标文件系统容量都已增加。如果只有 LV 变大，先处理文件系统扩展，不要重复增加 LV 容量。