免费开源的 Minecraft 启动器 PCL 上手指南：从快速开玩到专属界面定制全攻略
2026/10/23 4:40:36
凌晨两点被告警叫醒，监控面板上/data使用率 98%，日志写入已经开始报错。这种场面但凡维护过 Linux 服务器的人都不陌生。磁盘扩容这件事，命令就那么几条，真正让人栽跟头的是顺序、是文件系统类型判断、是分区表刷新这几个不起眼的环节。我见过太多人lvextend敲完就直接df -h，发现数字没变，然后开始怀疑人生。这篇就把linux磁盘扩容这条链路从底层结构到实操命令完整拆一遍，不管你是刚接手服务器的新人，还是干了几年偶尔还要上去救火的老手，都能从里面找到能直接抄的东西。
内容覆盖三个层面：一是扩容前怎么判断自己面对的是 LVM 还是裸分区、是 ext4 还是 xfs；二是完整的实操流程，包括云主机在线扩容后内核不认盘的处理；三是踩过的坑和报错速查。所有命令都经过实际环境验证，参数选择的原因我也会讲清楚，不做"照着敲就行"这种糊弄人的事。
1. 先搞清楚你面对的是哪种磁盘布局
1.1 扩容之前必须回答的四个问题
很多人一上来就fdisk -l看一眼，然后凭感觉敲命令。这个习惯很危险。磁盘扩容的操作路径完全取决于你机器的实际布局，动手之前至少有四个问题要有明确答案，答不上来就别碰键盘。
第一个问题：这块盘是整盘做的文件系统，还是分了区。整盘格式化（比如/dev/sdb直接mkfs）和分区后格式化（/dev/sdb1）的扩容方式完全不同，前者不需要动分区表，后者必须先扩分区。
第二个问题：分区之上有没有 LVM。有 LVM 的话，扩容链路会变成"磁盘 → 分区 → PV → VG → LV → 文件系统"这条长链，每一步都要执行对应命令；没有 LVM 就只有"磁盘 → 分区 → 文件系统"三步。判断方法很简单，lsblk的输出里如果看到sda3下面是centos-root、ubuntu-vg-root这种带连字符的名字，那就是 LVM。
第三个问题：文件系统是 ext4 还是 xfs。这两个扩容工具完全不通用，resize2fs遇到 xfs 会直接报错，xfs_growfs遇到 ext4 也一样。用df -T或者lsblk -f一眼就能看出来。
第四个问题：这块盘是在线扩容还是离线扩容。云主机的系统盘通常支持在线扩容，业务盘如果是数据盘，尽量挑低峰期做，虽然大部分操作支持在线执行，但磁盘 I/O 抖动是免不了的。
提示：四个问题里最容易搞错的是第二个。有些机器上
/dev/sda1是/boot，/dev/sda2才是 LVM 的 PV，扩容的时候扩错分区是灾难性的。
1.2 三条主流路径的选择逻辑
把上面四个问题答完，你的操作路径基本就确定了，无非三种情况。我整理成一张表，对照着看比较直观。
| 磁盘布局 | 典型场景 | 扩容链路 | 关键命令 |
|---|---|---|---|
| 整盘无分区 + ext4/xfs | 数据盘直挂 | 块设备 → 文件系统 | resize2fs/xfs_growfs |
| 分区无 LVM | 传统分区方案 | 块设备 → 分区 → 文件系统 | growpart+resize2fs |
| 分区 + LVM | 主流发行版默认 | 块设备 → 分区 → PV → LV → 文件系统 | growpart+pvresize+lvextend+ 扩容 FS |
这里有个容易被忽略的点：LVM 路径里，VG 这一层是"自动"变大的。pvresize执行完之后，PV 上多出来的空间会立刻进入所属的 VG，不需要额外命令。很多人卡在这里，以为还要vgextend一下，其实vgextend是往 VG 里加新的 PV 用的，扩容已有 PV 根本用不上。
至于为什么主流发行版都默认用 LVM，理由很实际：它把"物理空间"和"逻辑空间"解耦了。你可以在一个 VG 里划出多个 LV 分给不同目录，某个目录吃紧了，从别的 LV 匀一点过来就行，不用重新分区、不用迁移数据。代价就是多了一层抽象，扩容的时候命令多敲几条。
选择哪条路径不需要你决策，机器装成什么样就是什么样。但你要清楚自己站在哪条路径上，这决定了后面每一步该敲什么。
2. 磁盘扩容的分层原理与顺序约束
2.1 从物理块设备到文件系统的四层结构
理解分层结构是理解扩容顺序的前提。Linux 存储栈从下往上大致是这么几层：最底下是物理块设备，也就是dmesg里那个sda、vdb；往上是分区表定义的分区，sda1、sda2；再往上是 LVM 的 PV、VG、LV 三层抽象；最顶上才是文件系统，ext4 或者 xfs。
每一层都有自己的元数据，都要单独"通知"它容量变了。内核认不出新容量，上面所有层都白搭；分区表没更新，PV 就扩不动；PV 没扩，VG 里的空闲空间就是零；LV 没扩，文件系统再扩也是原大小。
用个生活化的类比：这就像一间办公室要扩建。先得有新的建筑面积（物理磁盘扩容），然后得在图纸上把新面积划进你的房间（分区表更新），接着物业要确认这块面积归你管（PV 扩容），公司要把这块面积分配到具体部门（LV 扩容），最后部门才能真正在里面摆桌子（文件系统扩容）。中间任何一步没做，桌子都摆不进去。
这个类比的核心是：每一层只认它下面那一层给自己的信息，不认物理现实。你把云盘从 100G 调到 200G，内核如果没重新读块设备容量，它依然以为这块盘是 100G，后面所有操作都建立在错误的前提上。
2.2 为什么扩容顺序绝对不能颠倒
顺序不能颠倒的原因在于依赖关系是单向的。上层容量的上限，永远受限于下层。
举个具体的例子。假设你把/dev/sda3从 50G 扩到了 80G，但忘了跑pvresize。这时候你去lvextend -l +100%FREE，会发现 VG 里根本没有空闲 PE，命令直接报 "Insufficient free space"。因为 VG 的空间统计是基于 PV 的元数据来的，PV 元数据里这块盘还是 50G，多出来的 30G 对 LVM 来说不存在。
反过来，如果你先lvextend再resize2fs，这个顺序是对的，因为文件系统扩容需要 LV 已经变大。但如果你resize2fs之后才想起来lvextend没做，那resize2fs会因为"目标大小等于当前大小"而直接返回成功，看起来没报错，实际什么也没干。
还有更隐蔽的一种：分区扩了，PV 也扩了，LV 也扩了，但文件系统用的是 xfs，你敲了resize2fs。因为resize2fs检测到不是 ext 系列文件系统会报错退出，这一步至少你能发现问题。但如果 LV 没扩、文件系统扩了，resize2fs会在达到 LV 边界时停下，并且告诉你 "The filesystem is already XXX blocks long. Nothing to do!"，这个提示很容易被忽略。
注意：
lvextend有一个-r参数，可以自动调用对应的文件系统扩容工具，省掉一步。我个人的习惯是不用它，一步一步来，每步都df -h确认一下，出问题好定位。自动化省的那几秒钟，抵不上排查故障花的时间。
2.3 ext4 与 xfs 的扩容机制差异
这两个文件系统的扩容工具差异，不只是命令名不一样，底层机制和限制条件也不同。搞清楚了才知道什么情况下不能做什么操作。
ext4 的resize2fs支持在线扩容（挂载状态下）和离线扩容，也支持缩容，缩容必须先卸载并跑e2fsck -f。扩容时它需要文件系统有足够的"预留块"来描述新增的空间，如果文件系统创建时预留的 inode 和块组不够，扩容会失败。这个问题在很小的文件系统上比较常见，正常几个 G 以上的基本不会遇到。
xfs 的xfs_growfs只支持扩容，不支持缩容，这是设计上的取舍。它必须挂载着才能扩容，因为扩容元数据是在挂载状态下通过日志提交的。这点和 ext4 不同，很多人习惯性卸载之后跑xfs_growfs，会直接报 "not a mounted XFS filesystem"。
还有一个细节：xfs 扩容的粒度是分配组（allocation group），扩容时新增的空间会按 AG 粒度切分，所以df -h看到的大小可能比 LV 略小一点点，这是正常的，不用慌。
| 对比项 | ext4 | xfs |
|---|---|---|
| 扩容命令 | resize2fs | xfs_growfs |
| 是否需挂载 | 均可 | 必须挂载 |
| 是否支持缩容 | 支持（需卸载） | 不支持 |
| 离线检查工具 | e2fsck -f | xfs_repair |
| 查看文件系统信息 | dumpe2fs -h | xfs_info |
3. LVM 场景的完整实操流程
3.1 第一步：把现场信息摸清楚
动手之前先采集信息，这是必须养成的习惯。我会跑这么一组命令，把结果贴到一个临时文件里，万一后面操作出岔子，至少知道原始状态是什么样。
# 块设备与挂载关系 lsblk -f # 分区表详情 fdisk -l /dev/sda # LVM 三层信息 pvs && vgs && lvs # 文件系统类型与使用率 df -Thlsblk -f的输出信息量最大，一次能看到设备名、文件系统类型、UUID、挂载点。我一般先看这个，然后pvs、vgs、lvs三个命令连着跑，把 PV 剩余空间、VG 剩余空间、LV 当前大小这三个数字记下来。
举个真实的输出形态，方便你对照：
NAME FSTYPE SIZE MOUNTPOINT sda 200G ├─sda1 xfs 1G /boot └─sda2 LVM2_member 199G ├─centos-root xfs 150G / └─centos-swap swap 4G [SWAP]从这个输出能读出几件事：盘是sda，MBR 还是 GPT 得看fdisk -l的第一行；sda2是 LVM 的 PV；根文件系统是 xfs，挂在/；/boot是独立的 xfs 分区，不参与这次的 LVM 扩容。如果/data也在上面，会多出一行centos-data，扩容时就要扩那个 LV。
提示：把上面这些命令的输出重定向到一个文件，比如
lsblk -f > /root/disk-before.txt，做完扩容再存一份 after 版本。这个习惯救过我一次，因为扩容中途发现/boot的 UUID 变了，靠对比文件才定位到问题所在。
3.2 第二步：让内核重新识别块设备
云盘在控制台调大容量之后，Linux 内核并不会自动知道这件事。这时候lsblk看到的还是旧容量，fdisk -l也是旧的分区表。必须主动触发一次重新扫描。
最直接的方法是告诉 SCSI 子系统重新读这块盘的容量：
# 方法一：直接写 rescan 节点（推荐） echo 1 > /sys/class/block/sda/device/rescan # 方法二：用 rescan-scsi-bus.sh 脚本（需要 sg3_utils 包） rescan-scsi-bus.sh -r # 方法三：重启……不推荐，但某些虚拟化平台只认这招执行完之后再跑fdisk -l /dev/sda，如果第一行的Disk /dev/sda: xxx GB数字变成了新容量，说明内核认到了。如果没变，检查一下云盘是否挂载到了正确的实例上，或者是不是需要先在控制台完成扩容确认操作。
这里有个坑要提前说：部分平台的系统盘扩容后，/sys/class/block/sda/device/rescan这个路径可能不存在，因为设备名不是sda而是vda或者nvme0n1。路径要对应替换，nvme盘的 rescan 路径通常是/sys/class/block/nvme0n1/device/rescan_controller，写法和 SCSI 盘不一样。
3.3 第三步：分区表与 PV 的衔接处理
内核认到新容量之后，分区表要跟上。这里的操作根据分区工具不同有两条路。
如果机器上有growpart（cloud-utils-growpart 包提供），它能自动算出分区应该扩到多大，一条命令搞定：
growpart /dev/sda 2第一个参数是磁盘，第二个是分区号。注意是sda 2不是sda2，中间有空格。这条命令会自己处理分区表修改和内核通知，不用担心partprobe那一步。
如果没有growpart，就得走fdisk手动路线。手动路线有一个必须牢记的铁律：删除分区再重建时，起始扇区必须和原来完全一致。起始扇区变了，分区里的数据就找不回来了。操作步骤如下：
fdisk /dev/sda # p 打印分区表，记下 sda2 的 Start 扇区 # d 删除分区 # 2 选择分区号 2 # n 新建分区 # p 主分区 # 2 分区号还是 2 # <起始扇区> 必须手动输入刚才记下的那个数字 # <结束扇区> 直接回车用默认值（吃掉全部剩余空间） # N 如果提示是否删除 xfs 签名，选 N # p 再次确认分区表 # w 写入w写入之后，内核会提示 "The kernel still uses the old table"，这时候跑一次partprobe /dev/sda或者partx -u /dev/sda2。如果分区正被占用（比如是根分区），partprobe可能会报设备忙，那就只能重启，或者用partx更新单个分区。
分区扩完之后，lsblk里sda2的 SIZE 应该变成新的大小。接下来扩 PV：
pvresize /dev/sda2 pvspvs输出里的PFree应该变成一个正数，这个数就是新加进来的空闲空间。到这一步，VG 已经自动变大了，vgs里的VFree也是同一个数字。
3.4 第四步：LV 与文件系统的递进扩容
现在空间在 VG 里躺着，要分配给具体的 LV。先确认目标 LV 的名字，从lvs的输出里看，比如要扩根分区就是centos-root。
# 方式一：吃掉 VG 里全部空闲空间 lvextend -l +100%FREE /dev/centos/root # 方式二：扩指定大小（比如加 20G） lvextend -L +20G /dev/centos/root # 方式三：直接指定最终大小 lvextend -L 200G /dev/centos/root-l +100%FREE里的l是小写，表示按 PE 个数计算，%FREE是 VG 空闲空间的比例；-L是大写，按绝对容量算。这两个参数经常有人写混，-l +100%FREE写成-L +100%FREE会报语法错误。
LV 扩完之后，lsblk里 LV 的 SIZE 变了，但df -Th里的数字还没变，因为文件系统还不知道这件事。最后一步按文件系统类型分：
# ext4 resize2fs /dev/centos/root # xfs（必须挂载状态下执行） xfs_growfs /xfs 的参数是挂载点不是设备路径，这点特别容易搞错。xfs_growfs /dev/centos/root也能工作，但推荐用挂载点，语义更清楚。如果目标是/data，就写xfs_growfs /data。
执行完之后df -Th确认，数字变成新的容量，整个链路就打通了。从头到尾，我习惯在每一步之后都跑一次lsblk或者df -h，确认这一步真的生效了再往下走。一次性敲完一串命令看起来很帅，出问题的时候就很难定位是哪一步断的。
3.5 在线扩容与离线扩容的取舍
LVM 的一大优势是支持在线扩容，几乎所有步骤都不需要停机。但"能"和"该"是两回事。
在线操作的风险主要来自 I/O 抖动。pvresize要更新 PV 元数据，lvextend要修改 VG 元数据，这些操作会短暂阻塞相关设备的 I/O。对于高并发的数据库服务，哪怕几百毫秒的阻塞也可能触发连接超时。我的经验是：业务盘尽量约在低峰期，系统盘如果实在没法停机，就挑请求量最低的窗口，操作前先看一眼监控。
有些操作在根分区上必须在线做，因为根分区根本没法卸载。xfs_growfs /是纯在线操作，resize2fs对挂载中的 ext4 也是安全的，这两个步骤不用担心。真正需要注意的反而是partprobe，如果根分区所在的盘分区表变了，partprobe会被拒绝，这时候要么重启，要么用partx -u只更新单个分区。
离线扩容的优势是能先把e2fsck跑一遍。ext4 文件系统如果在扩容前有潜在错误，在线扩容过程可能会把错误放大，甚至导致文件系统损坏。数据盘如果能卸载，我一般建议先umount，e2fsck -f检查一遍，再扩容。
注意：用
umount之前一定要确认没有进程占用，lsof +D /data或者fuser -mv /data看一眼。卸载失败硬来，轻则进程崩溃，重则数据不一致。
4. 非 LVM 场景的扩容方法
4.1 growpart 一把梭的前提条件
非 LVM 的分区扩容，其实比 LVM 简单，因为链路短。但"简单"不等于"不会出错"，growpart虽然一条命令能搞定分区表，它对前提条件是有要求的。
第一个前提：分区必须是这块盘上的最后一个分区。如果是中间的分区，后面还有别的分区占着空间，growpart没法把后面的分区挪走，会直接失败。这种情况只能重新规划布局，或者先把后面的分区备份出来删掉重排。
第二个前提：分区表类型要支持。MBR 分区表单个分区最大 2T，超过这个大小就得转 GPT。转换分区表不是无损操作，需要先把数据备份出来。如果一块 4T 的盘用 MBR 分区，扩到 2T 以上一定会失败，报错信息大概是 "partition size exceeds maximum"。
第三个前提：文件系统本身支持在线扩容。ext4 和 xfs 都支持，其它文件系统不一定。用df -T看一眼，如果是 zfs、btrfs，扩容命令完全不同，别套用这篇文章的流程。
命令形态：
growpart /dev/sdb 1执行后的输出类似CHANGED: partition=1 start=2048 old: size=209713152 end=209715199 new: size=419428319 end=419430366，看到CHANGED就成功了。如果输出NOCHANGE，说明分区已经是最大了，检查一下磁盘本身是不是真的扩容成功了。
4.2 分区序号错位的补救办法
有一种情况很常见：扩容之后growpart /dev/sdb 1报错unable to satisfy the request，但盘确实已经变大了。原因通常是分区表里记录的"剩余空间"和实际不符，或者分区后面藏着一个扩展分区。
先跑fdisk -l /dev/sdb看看分区布局。如果是 MBR 盘，分区 1 后面可能跟着一个扩展分区 2，而扩展分区里又有逻辑分区 5。这种布局下分区 1 是扩不动的，只能扩逻辑分区 5。
另一种情况是分区表有残留的"备份"信息，导致工具算错。sgdisk -v /dev/sdb可以检查 GPT 盘的一致性，parted /dev/sdb print free能看到每个间隙的具体位置。我遇到过一块盘，parted显示分区 1 后面有 500G 空闲，但growpart死活不行，最后发现是分区表末尾的备份头位置不对，用sgdisk -e /dev/sdb修正之后才正常。
还有一类"错位"是人为造成的：有人先resize2fs再去扩分区，顺序反了。这种补救起来最麻烦，因为文件系统已经按照错误的边界在写了，只能先缩回原大小（ext4 可以，xfs 不行），再按正确顺序重来。
提示：如果分区扩了但文件系统扩不动，
dumpe2fs -h /dev/sdb1看看Block count和分区大小是否匹配。ext4 扩容失败常见的报错是 "New size smaller than existing size"，这句话字面意思是新大小更小，实际往往是分区根本没扩成功。
4.3 GPT 与 MBR 的边界差异
这两个分区表的差异点在扩容时会被放大，值得单独说一下。
MBR 用 32 位表示扇区地址，按 512 字节扇区算，最大寻址 2T。一块 4T 的盘用 MBR 分区，实际能用到的还是 2T，剩下 2T 是"未分配"状态。fdisk对 MBR 盘还有"主分区最多 4 个"的限制，扩分区时如果 4 个主分区已经用满，连重建都做不到。
GPT 用 64 位，寻址空间大到不用担心，而且没有 4 个主分区的限制，默认支持 128 个分区。它的分区表有两份，一份在盘头，一份在盘尾，扩容之后备份分区表的位置需要跟着调整，sgdisk -e /dev/sdb就是干这个的。
用parted /dev/sdb print看第一行的Partition Table:，写的是msdos就是 MBR，写gpt就是 GPT。如果是 msdos 而且盘已经超过 2T，扩容之前必须做分区表转换。转换有风险，sgdisk -g /dev/sdb可以在保留分区的情况下把 MBR 转 GPT，但这一步我强烈建议先做磁盘快照，别在生产环境上闭着眼跑。
5. 常见报错与排查实录
5.1 典型报错速查表
下面这张表是我这几年攒下来的，按报错信息反查原因，比从头捋流程快得多。
| 报错信息 | 实际原因 | 处理方式 |
|---|---|---|
Insufficient free space: X extents needed, but only 0 available | VG 里没空闲空间，多半是pvresize没做 | 回退执行pvresize /dev/sda2 |
The filesystem is already XXX blocks long. Nothing to do! | 文件系统已经是最大了，检查 LV 是不是没扩 | lvs确认 LV 大小 |
resize2fs: Bad magic number in super-block | 文件系统不是 ext 系列，或者设备路径写错 | df -T确认类型，xfs 用xfs_growfs |
xfs_growfs: /dev/sdb1 is not a mounted XFS filesystem | xfs 必须在挂载状态下扩容 | 先挂载或改用挂载点作参数 |
Device or resource busy | 分区被占用，partprobe无法更新 | 用partx -u /dev/sda2或重启 |
WARNING: Re-reading the partition table failed | 分区表写入成功但内核未更新 | partprobe或partx -u，根分区需重启 |
No space left on device（lvextend 后仍有） | inode 用尽，不是块用尽 | df -i查看，考虑重建文件系统 |
growpart: unable to satisfy the request | 分区不是最后一个，或有残留分区表 | parted print free查看间隙 |
表里最后一条特别值得展开。df -h显示还有空间，但写文件报No space left on device，八成是 inode 用完了。df -h看的是块使用率，df -i看的才是 inode。大量小文件（比如缓存目录、邮件队列）耗尽 inode 之后，磁盘扩容是解决不了的，得清理文件或者重建文件系统并指定更大的-N参数。
5.2 根分区占用导致无法操作的绕行方案
根分区扩容最麻烦的地方在于它一直处于挂载状态，很多"需要卸载"的操作做不了。好消息是，LVM + ext4/xfs 这条链路里，除了partprobe之外，其它步骤都能在线完成。
真正卡住的是分区表更新。fdisk写完w之后，内核会尝试重读分区表，但如果分区正被根文件系统使用，会返回失败。这时候有三种绕法。
第一种是用partx只更新指定分区，它不重读整张表，只调整指定分区的内核元数据：
partx -u /dev/sda2第二种是kpartx -u /dev/sda，原理类似，对某些虚拟化平台更稳。
第三种是重启。听起来简单粗暴，但云主机重启一次的成本可能比折腾半天还低。我在测试环境上基本直接重启，生产环境看业务容忍度。
还有一种极端情况：/boot是独立分区，扩容根分区不影响它，但如果/boot所在的分区在盘上位置靠后，扩根分区的时候可能不小心动到了它。这种布局在扩容前一定要fdisk -l看清楚分区顺序，别看到/dev/sda2就以为那是根分区。
注意：根分区扩容完成之后，
/etc/fstab里如果有用 UUID 挂载的条目，确认一下 UUID 有没有变化。正常扩容不改 UUID，但如果是"删除分区重建"的操作，某些情况下 UUID 会变，重启之后会挂载失败进不了系统。
5.3 扩容之后空间没变化的五种原因
这是最高频的问题，df -h数字没变，人就开始慌。按下面这个顺序排查，基本都能定位。
第一，文件系统那一步没做。LV 扩了但没跑resize2fs或xfs_growfs，这是最常见的，lsblk里 LV 是新大小，df里是旧大小，两边对不上就是这个原因。
第二，命令报错了但被忽略了。resize2fs在某些情况下会输出 "Nothing to do"，退出码是 0，看起来成功实际没动。养成看输出内容的习惯，别只看退出码。
第三，扩错了 LV。机器上有多个 LV 的时候，lvextend写错名字很常见。lvs对一下，确认扩的是挂载到目标目录的那个。
第四，扩错了分区。sda1是/boot，sda2是 LVM，扩了sda1当然看不到根分区的变化。lsblk -f看挂载点对应关系。
第五，容器或挂载命名空间的问题。如果在容器里执行扩容命令，看到的是容器内的挂载视图，宿主机上可能已经改了但容器没感知。这种情况需要到宿主机上确认，或者重启容器。
排查的时候我一般用这条"三连"：
lsblk /dev/sda # 看块设备和分区大小 pvs && lvs # 看 LVM 各层大小 df -Th # 看文件系统大小三层数字一路对下来，哪一层跟上一层不匹配，问题就在哪一层。
6. 保命操作与实操心得
6.1 动手之前的三件保命事
磁盘操作是不可逆的，删错了分区、写错了分区表，数据可能就没了。所以动手之前有三件事必须做，这不是形式主义，是真的能救命。
第一件，做快照。云主机直接打快照，物理机至少把关键数据备份到另一块盘上。快照的成本是几分钟，误操作的成本可能是几个通宵加一堆道歉。我见过有同事在根分区上fdisk手滑删错了分区，最后是从快照恢复加重新调数据，折腾了一整天。
第二件，记录原始状态。前面提到的lsblk -f、pvs、lvs、fdisk -l、df -Th输出全部存文件。不只是为了出问题对比，也是为了确认自己操作前的判断是对的。有一次我准备扩/data，看记录才发现/data根本不是独立分区，是根分区下的一个目录，差点扩错地方。
第三件，确认有没有别的机器依赖这台机器。NFS 服务端、数据库主库、消息队列节点，这些角色一旦因为扩容操作短暂不可用，影响面比你想的大。扩容前给相关方打个招呼，比事后解释省事。
这三件事看起来啰嗦，实际的成本也就十来分钟。做运维这些年，我一半以上的"事故复盘"最后都归结到"当时没做快照"或者"当时没记录原始状态"。
6.2 我踩过的几个坑
说几个具体的，都是真实遇到过、也经常看到别人踩的。
第一个坑：lvextend -l +100%FREE之后忘了resize2fs。当时是在一个批量脚本里执行的，脚本把lvextend的返回码当成了判断依据，lvextend成功就认为扩容完成。结果一周后告警又响了，一查 LV 是 200G，文件系统还是 150G，中间 50G 一直闲置。后来我在脚本里加了一步resize2fs或者xfs_growfs，并且用df的实际数值做校验，才算彻底解决。
第二个坑：xfs 文件系统跑resize2fs。早期的镜像全是 ext4，后来换成了 CentOS 7 默认 xfs，脚本没改。resize2fs报错还好，问题是当时的脚本把 stderr 重定向到了/dev/null，报错信息全被吞了，只看到退出码非零。排查的时候看了半天日志才反应过来是文件系统类型变了。
第三个坑：growpart在 MBR 和 GPT 上的行为差异。有一批老机器的系统盘是 MBR 分区表，盘扩到 2T 以上之后growpart一直失败，报错信息看不懂。后来parted print才发现是 MBR 的寻址上限。这批机器最后是新建了数据盘挂上去，把大数据目录迁过去，比转换分区表风险低。
第四个坑：容器里执行扩容。在 Kubernetes 的 Pod 里看到df空间不足，直接在 Pod 里跑扩容命令，当然没效果。容器看到的/dev/sda是宿主机映射进来的，扩容必须在宿主机层面做，容器只能被动感知。这个坑很多人第一次都会踩。
第五个坑：partprobe之后没验证。有一次partprobe明明返回 0，但lsblk里分区大小没变。原因是那块盘是 NVMe，分区表的更新需要另外触发。后来加了一步验证，lsblk里的大小和fdisk -l里的一致了才继续下一步。这个验证习惯保留到现在，每一步都验证，不验证不往下走。
最后分享一个小技巧：如果你不确定某条命令会不会出问题，先在测试机上跑一遍，或者在fdisk里用p命令预览，确认无误再w写入。fdisk在写入之前所有的操作都只存在于内存里，退出不写就什么都没发生，这个"预览"机制救过我很多次。扩容这件事本身不难，难的是对细节保持敬畏，每敲一条命令之前想清楚它要做什么、做完之后怎么验证。养成这个节奏，磁盘扩容就不会再是一个让人心跳加速的操作了。