上个月收到监控告警，说根分区使用率 92%。

登录上去 df -h 一看，四十个 G 的盘只剩三个多 G。du -sh /* 挨个看，/var/lib/docker 占了大头，还有一堆构建缓存。

清了一轮，回到 60%。但我知道这只是暂时的，服务还在长，早晚得扩。

还好当初装系统的时候选了 LVM。要是普通分区，扩容就得停机、进救援模式、用 fdisk 调分区，风险大得多。

先理清楚 LVM 的三层

很多人被 LVM 绕晕，是因为它的名字太多。其实就三层。

物理层是 PV，Physical Volume，一块硬盘或者一个分区，初始化之后交给 LVM 管。

中间层是 VG，Volume Group，一个池子，把多个 PV 合成一个大的存储空间。

上层是 LV，Logical Volume，从池子里划出来的一块，格式化之后挂载使用。

扩容的时候，顺序是从下往上。先让 PV 变大，VG 才会跟着变大，然后才能扩 LV，最后扩文件系统。

搞反了就白做。

看现在的状态

1

lsblk

输出大概是这样：

1
2
3
4
5
6
7
8

NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda             254:0    0   40G  0 disk
├─vda1          254:1    0    1M  0 part
├─vda2          254:2    0  512M  0 part /boot/efi
└─vda3          254:3    0 39.5G  0 part
  ├─vg0-root    253:0    0   20G  0 lvm  /
  ├─vg0-swap    253:1    0    2G  0 lvm  [SWAP]
  └─vg0-data    253:2    0 17.5G  0 lvm  /data

这块盘 40G，vda3 是 LVM 的物理分区，占了 39.5G。里面划了三个 LV。

问题是我这块盘本来就只有 40G，没有剩余空间。所以要扩，得先给虚拟机加盘。

加盘

在云控制台或者虚拟化平台里，把磁盘从 40G 调到 80G。这一步在云厂商那边点一下就行，不用停机。

加完之后，虚拟机里 lsblk 还是显示 40G，因为内核还没重新读分区表。

1
2

lsblk
# vda 显示 80G，但 vda3 还是 39.5G

这就是关键的一步。vda 本身变大了，但 vda3 这个分区没变。

扩分区

有两种情况。

如果你用的是 GPT 分区表，而且分区后面没有别的分区，用 growpart 最省事：

1

sudo growpart /dev/vda 3

growpart 是 cloud-utils-growpart 包里的工具，大部分云镜像都预装了。

如果没装，apt install cloud-utils-growpart 或者 yum install cloud-utils-growpart。

跑完再看：

1

lsblk

vda3 应该变成 79.5G 了。

如果是 MBR 分区表，growpart 也能处理，但有个限制，主分区最多四个，而且扩展分区后面的空间不好扩。这种情况下得用 fdisk 删了重建分区，fdisk 的 d 删分区只删分区表项，不动数据，只要起始扇区没变就是安全的。不过操作的时候手要稳。

让 PV 认识新的大小

分区变大了，但 LVM 还不知道。因为 PV 里记录了自己的大小。

1

sudo pvresize /dev/vda3

这个命令会让 PV 重新读取分区的大小，然后更新自己的元数据。

验证：

1

sudo pvs

输出里的 PSize 应该变成 79.5G，PFree 是新增的空间。

如果 PFree 没变，说明 pvresize 没生效，回头检查分区是不是真的扩了。

扩 LV

1

sudo lvs

看当前的 LV 大小。

扩的时候有两种写法。

按绝对值扩到某个大小：

1

sudo lvextend -L 40G /dev/vg0/root

注意 -L 是最终大小，不是增量。如果你写 -L 40G 而当前已经是 40G，它什么都不会做。

按增量扩：

1

sudo lvextend -L +20G /dev/vg0/root

这个更直观，加二十个 G。

或者干脆把池子里的空间全用掉：

1

sudo lvextend -l +100%FREE /dev/vg0/root

注意这里是小写的 -l，后面跟百分比。大写的 -L 后面跟具体数值。这个大小写很容易看错。

扩文件系统

这一步最容易被忘。LV 变大了，但上面的文件系统还是原来的大小，df -h 看不出变化。

ext4 用：

1

sudo resize2fs /dev/vg0/root

不用给大小，它会自动扩到 LV 的边界。

xfs 用：

1

sudo xfs_growfs /

注意 xfs 的 xfs_growfs 参数是挂载点，不是设备名。写 /dev/vg0/root 会报错。

这是两个文件系统最明显的区别。ext4 可以缩，xfs 只能扩。所以如果你的盘用 xfs，规划的时候要留点余量，缩不回去。

在线扩容

好消息是，上面这些操作除了 growpart 之外，全都可以在线做，不用卸载不用停机。

ext4 从内核 3.6 开始支持在线扩容，resize2fs 会自动检测并走在线模式。xfs 一直是在线的。

我用的是 ext4，整个流程在跑着服务的机器上做完，中间没有中断。nginx 和数据库都没感觉。

不过还是建议在业务低峰做。虽然理论上是安全的，但万一 growpart 把分区表写坏了，那就是大事故。

一次完整的操作

把上面的命令串起来，加上 df 前后的对比：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 扩容前
df -h /

# 分区扩容
sudo growpart /dev/vda 3

# PV 重新读取
sudo pvresize /dev/vda3

# LV 扩容
sudo lvextend -l +100%FREE /dev/vg0/root

# 文件系统扩容
sudo resize2fs /dev/vg0/root

# 验证
df -h /

我实际跑的时候，每一步之间都 lsblk 或 pvs 确认一下。多敲几条命令，比出问题再回头找强。

几个坑

growpart 之后忘了 pvresize，这是最常见的。pvs 里 PFree 是 0，你就会以为是分区没扩成功，其实只是 LVM 不知道。

lvextend 用了 -L 但写的是增量值，比如 -L 20G 而当前已经是 20G，它什么都不做，也不报错。

xfs 用 resize2fs 会直接报错说不支持，别慌，换 xfs_growfs。

还有一个，如果你的 /boot 在 LVM 上，扩它是可以的，但 grub 那边可能需要重新生成配置。我这个机器的 /boot 是独立分区，没在 LVM 里，所以没遇到。

缩容的注意事项

扩容易，缩难。

ext4 缩容要三步。先 umount，然后 e2fsck -f 检查，再 resize2fs <设备> <目标大小>，最后 lvreduce。

顺序不能反。先缩文件系统再缩 LV。如果先缩 LV，文件系统就损坏了，数据基本找不回来。

xfs 根本不支持缩容。要用 xfs 又想缩，只能备份、重建、恢复。

所以我的建议是，宁可一开始规划得保守一点，也不要给自己留缩容的活。

磁盘规划的一点经验

装系统的时候我习惯这么分：

/boot 给 512M，独立分区，不在 LVM 里。这是为了让 grub 和系统救援都能正常工作。

swap 给内存的一到两倍，但不超过 4G。现在很多云厂商建议不给 swap，我的看法是留一点，防止突发的内存尖峰直接把进程打死。

/ 给剩下的全部。不用单独分 /var 和 /home，因为 LVM 的好处就是可以动态调，一开始分太细反而失去了灵活性。

这样分下来，如果哪天 /var/lib/docker 涨得太快，我直接扩根分区就行，不用去动别的。

现在的状态

扩到 80G 之后，根分区用了 38%，/data 那边还有空间。跑了一个多月，稳定。

顺手做了两件事。一是给 docker 加了 data-root 的迁移，把镜像目录挪到了 /data 下面，这样系统盘的压力小很多。二是加了个监控，磁盘到 85% 就推消息，不用等到 92% 才被叫醒。

LVM 这个东西，平时感觉不到它的存在，真正需要的时候才发现它的好。当初装系统多勾了一个选项，省了今天一晚上的事。