1. 扩容前的系统状态评估
1.1 先搞清楚当前磁盘布局
给 Centos 做分区扩容，最怕的就是拿到一台机器上来就敲命令。我见过不少朋友在/dev/sda上直接fdisk /dev/sda删分区重建，结果数据全没了，因为根本没有先确认这台机器的底层存储方案到底是什么。
接手任何一台需要扩容的 Centos 机器，第一步永远是做信息采集。我的习惯是先跑三组命令：
lsblk df -hT fdisk -llsblk看的是整个块设备的树形结构，能一眼看出磁盘、分区、逻辑卷之间的从属关系；df -hT看的是文件系统当前的使用率和类型，判断到底哪里满了；fdisk -l看的是最底层的分区表信息，确认分区类型是 MBR 还是 GPT。三组命令结合起来，基本能把一台机器的存储拓扑摸清楚。
这里要特别提醒一点，很多人只看df -h，发现根分区满了就开始折腾。但根分区满只是一个表象，你要搞清楚它到底是跑在物理分区上、LVM 逻辑卷上，还是跑在云平台的块存储上，三种场景的扩容路径完全不一样。如果底层是 LVM，后续扩容会轻松很多；如果是物理分区直接格式化挂载，那就得走分区表调整的老路，风险和处理流程截然不同。
1.2 判断文件系统类型决定后续操作
拿到df -hT的输出后，重点看 Type 这一列。Centos 6 时代默认是 ext4，Centos 7 开始默认变成 xfs，Centos 8/9 依然沿用 xfs。这两种文件系统的扩容方式有本质区别：
| 文件系统类型 | 扩容工具 | 是否支持在线扩容 | 是否支持缩小 |
|---|---|---|---|
| ext4 | resize2fs | 支持挂载状态下直接扩容 | 支持缩小，但风险较高 |
| xfs | xfs_growfs | 支持挂载状态下直接扩容 | 不支持缩小，只能扩大 |
xfs 的设计哲学就是"只能增不能减"，所以如果你建的是 xfs 文件系统，扩容时不用卸载分区，直接拉大后执行xfs_growfs就能生效。而 ext4 在线扩容也基本是常规操作，两者在"扩大"这个方向上都非常成熟，遇到需要缩小的情况就只能绕道了。
另外还要确认分区表格式。fdisk -l输出里如果看到 "Disk label type: dos" 就是 MBR 分区表，看到 "gpt" 就是 GPT。MBR 单块磁盘支持最大 2TB，而且最多只能建 4 个主分区；GPT 没有这些限制。现在新机器基本都是 GPT，但早期虚拟机模板和旧物理机还大量存在 MBR，扩容时如果磁盘超过 2TB，MBR 会直接变成拦路虎。
提示：
pvs、vgs、lvs三个命令可以快速确认系统是否在用 LVM。如果lsblk输出里能看到vg或lv字样，说明这台机器走的是逻辑卷管理，后面的扩容路径会完全不一样。
2. 磁盘挂载与 LVM 扩容的核心流程
2.1 认识 LVM 的三层抽象
Centos 默认安装时，如果选择的不是"自动分区"，而是手动配置过逻辑卷，那么根分区所在的存储层级通常是这样的：
物理磁盘（Physical Disk）→ 物理卷（PV，Physical Volume）→ 卷组（VG，Volume Group）→ 逻辑卷（LV，Logical Volume）→ 文件系统
这个结构可能一开始看着有点绕，但举个生活化的例子就很好理解。把物理磁盘想象成一大块原始面粉，PV 就是把面粉称量好、分装好的独立袋子，VG 是一个大储物柜，多个 PV 袋子的面粉可以都倒进这个大柜子里，LV 则是从柜子里取出来的面粉团，专门用来做特定的面包（也就是挂载到某个目录的文件系统）。
LVM 最核心的价值在于，它把底层物理磁盘的容量变化和上层文件系统的容量变化解耦了。物理磁盘不够用时，加入新硬盘或者扩大虚拟磁盘，把新增的空间划给 PV，再扩充到 VG，再从 VG 里划给 LV，最后才扩展文件系统。每一步都有对应的命令，任何一步都可以停下来检查，出错也能回退，这是物理分区直接扩容无法比拟的优势。
2.2 新磁盘加入与 PV/VG 扩展
如果原系统是 LVM 布局，扩容路径就非常顺畅。假设我们把虚拟机的虚拟磁盘从 40G 扩到 100G，新出现的空间在/dev/sda末段，开始操作：
# 重新扫描磁盘，让内核识别新增的容量 partprobe /dev/sda lsblk如果lsblk已经能看到磁盘总容量变成 100G，但分区大小还是旧的，就需要新建一个分区来使用剩余空间。用fdisk操作时，注意分区类型设置为 Linux LVM（8e）：
fdisk /dev/sda # 交互式操作：n（新建分区） → p（主分区） → 回车选默认扇区 → t（改类型） → 8e → w（保存）新分区建好后，把它变成 PV，再并入卷组：
# 创建新的物理卷 pvcreate /dev/sda3 # 扩展到卷组 vgextend centos /dev/sda3 # 查看卷组容量变化 vgdisplayvgdisplay里重点看 Free PE / Size 这一行，这里显示的就是当前卷组里还没被分配给逻辑卷的空闲容量。如果这里没有容量剩余，后面的 LV 扩展就无从谈起，很多新手在这里卡住，以为操作错了，其实是前面的 vgextend 没生效，或者分区类型没设对。
2.3 逻辑卷扩展与文件系统在线扩容
VG 里有空闲容量后，就可以扩展 LV 了。假设根逻辑卷名字叫/dev/centos/root，把容量扩大 60G：
# 扩展逻辑卷 lvextend -L +60G /dev/centos/root # 扩展文件系统（xfs 和 ext4 命令不同） xfs_growfs /dev/centos/root # xfs 文件系统 resize2fs /dev/centos/root # ext4 文件系统这里有一个很容易踩的坑：lvextend只是扩大了逻辑卷的容量边界，文件系统本身并不知道这个变化。如果不执行xfs_growfs或resize2fs，df -h看到的容量依然不变，等于白扩。反向操作也一样，每次都有人说"我 lvextend 了为什么 df 没变化"，十有八九就是漏了文件系统扩展这一步。
另外，xfs 文件系统在挥动xfs_growfs的魔杖时，其实可以挂载状态下直接执行，根本不需要卸载。只要逻辑卷的设备映射存在，命令就能在线完成扩展。ext4 也同样支持在线扩容，现在的生产环境基本都能做到不停机扩容。
注意：
resize2fs是老牌的 ext 系列工具，xfs_growfs是 xfs 专用工具，两者不要混用。如果你不确定当前文件系统是什么类型，执行blkid /dev/centos/root就能看到 TYPE 字段。
3. 非 LVM 场景的分区扩容实操
3.1 物理分区直挂的场景如何扩展
Centos 如果安装时选择的是标准分区而不是 LVM，比如/dev/sda1是/boot，/dev/sda2是根分区，直接格式化成了 xfs，那么扩容路径就没有 LVM 那么优雅了。核心思路是：调整分区表 → 让内核重新读取分区大小 → 扩展文件系统。
虚拟机场景下，一般先把虚拟磁盘大小加大。VMware 里在虚拟机设置中扩展磁盘容量，VirtualBox 用命令行：
VBoxManage modifymedium disk /path/to/disk.vdi --resize 102400宿主机层面扩展完，进入 Centos 后先执行lsblk确认磁盘空间是否已经识别。如果磁盘容量识别了，但分区大小没变，用fdisk删除旧分区再重建。这里是最危险的一步，因为重建分区的起始扇区必须和原来完全一致，否则分区数据直接丢失。
我的建议是，进入fdisk交互界面后，先按p查看分区表并截图记录下 Start 列的值。删除分区时按d删掉目标分区，然后按n重建，起始扇区必须填入记录下来的原始值，结束扇区默认是磁盘末尾就行。确认无误后按w写入分区表，然后执行：
partprobe /dev/sda如果提示设备忙，可能是分区正在使用，可以重启系统让内核重新读取分区表。
3.2 文件系统层面如何扩大 xfs/ext4
分区表更新后，现在的分区已经变大，但文件系统还是老样子。此时执行df -h会发现容量没变，因为文件系统的元数据还记录着旧的大小。需要用对应工具把它撑满到整个分区：
# xfs 文件系统 xfs_growfs /mount/point # ext4 文件系统 resize2fs /dev/sda2注意 xfs 的参数是挂载点而不是设备文件路径，ext4 的 resize2fs 参数是设备文件路径。两个命令的传参方式不一样，我一开始也经常记混，后来总结了个记忆方法：xfs_growfs 里的 growfs 后面跟的是文件系统能看到的地方，也就是挂载点；resize2fs 操作的对象是块设备本身。
这里需要特别提一下 GPT 分区表的情况。如果磁盘超过 2TB 或者用的是 UEFI 引导，分区表往往不是 MBR 而是 GPT，操作时用gdisk或者parted更合适。fdisk新版也支持 GPT，但老版本可能识别异常，操作前先确认工具版本和分区表格式。
对于parted，常用的是resizepart命令：
parted /dev/sda # 交互界面中执行： # resizepart 2 100% # quit这种操作方式比 fdisk 的删分区重建更安全，因为它允许直接调整现有分区的结束位置，不会动起始扇区，极大降低了误操作风险。在新版 Centos 上，我反而更推荐用parted的 resizepart 来做整盘扩容。
提示：如果根分区直接处于挂载状态，
partprobe会提示 "Device or resource busy"，这时可以尝试partprobe -s查看状态，或者直接重启。生产环境在业务低峰期操作，千万不要在数据盘读写频繁时强行重读分区表。
3.3 数据备份与回滚方案的兜底
非 LVM 的分区扩容，本质上是一次"修改元数据"的操作，虽然工具已经非常成熟，但任何意外断电、参数填写错误都可能造成数据损坏。所以操作前强制做好备份非常必要。
最简单的做法是用dd备份分区表区域（注意不要备份整个磁盘，那太耗时了）：
# 备份 MBR 前 512 字节（包含分区表） dd if=/dev/sda of=/tmp/mbr_backup.bin bs=512 count=1 # 恢复时执行 dd if=/tmp/mbr_backup.bin of=/dev/sda bs=512 count=1如果是 GPT 分区表，分区表信息会分布在磁盘头部和尾部，用sgdisk命令更可靠：
# 备份分区表 sgdisk --backup=/tmp/gpt_backup.sgdisk /dev/sda # 恢复分区表 sgdisk --load-backup=/tmp/gpt_backup.sgdisk /dev/sdadd备份只覆盖 MBR 场景，GPT 用户千万别只靠 dd 备份那 512 字节，因为 GPT 的备份分区表是存在磁盘末尾的，单靠前 512 字节恢复不完整。这类细节只有在真正操作过大量机器之后才会注意得到。
当然，最稳妥的方案还是对关键数据做文件级别的备份，比如用rsync同步到独立目录或者远程机器。分区扩容本质是低风险高影响的动作，备份的意义不在于常用，而在于万一出问题时能兜底。
4. 开机自动挂载与常见问题排查
4.1 配置 fstab 实现自动挂载
扩容完成、文件系统扩展完毕之后，还有一个重要问题不能忽视——重启后新增分区或数据盘能不能自动挂载回来。
很多人以为扩容完整个流程就结束了，重启后才发现数据盘没挂载，业务直接报错。这个问题的根源在于/etc/fstab文件里根本没有新增分区的挂载记录，系统启动时自然不知道要挂载它。
编辑/etc/fstab时，不要直接用设备名（如/dev/sda1），因为在多块磁盘场景下，设备名可能会因为内核识别顺序不同而漂移，今天 sda 明天可能变成 sdb，挂载就会错乱。推荐用 UUID 的方式：
# 查询分区或逻辑卷的 UUID blkid /dev/sda3拿到 UUID 后，在/etc/fstab添加一行：
UUID=xxxx-xxxx-xxxx /data xfs defaults 0 0四个字段的含义分别是设备标识、挂载点、文件系统类型、挂载参数。最后的两个数字，第一个是 dump 备份标志，一般写 0；第二个是 fsck 检查顺序，根分区写 1，其他分区写 2 或 0。很多人直接写成defaults 1 1，结果开机时系统对非根分区执行 fsck，反而可能拖慢启动甚至报错，所以非根分区写0 0是更稳妥的选择。
编辑完 fstab 后，一定要执行一次验证：
mount -a这条命令会按照 fstab 的配置重新挂载所有条目，如果配置错误会立即报错，而不是等到重启才暴露。我见过不少人改完 fstab 就直接重启，结果起不来，最后只能进救援模式修改，非常折腾。
4.2 扩容后常见报错的排查思路
扩容过程中最典型的报错，我整理成一张排查表，基本覆盖了 90% 的现场问题：
| 症状 | 可能原因 | 排查与解决方案 |
|---|---|---|
df -h容量没变 | 执行了 lvextend 或分区调整，但没执行文件系统扩展命令 | 根据文件系统类型执行xfs_growfs或resize2fs |
partprobe报设备忙 | 分区正被系统使用，无法重读分区表 | 重启系统，或确认没有进程占用后再次执行 |
xfs_growfs报错 "not found" | 系统未安装 xfsprogs 工具包 | yum install -y xfsprogs或dnf install -y xfsprogs |
| 挂载时报 "wrong fs type" | 文件系统类型写错了 | 用blkid确认实际类型，修正 fstab 第三列 |
| 开机后进入紧急模式 | fstab 配置错误 | 输入 root 密码，修复 fstab，执行mount -a验证 |
vgextend原卷组不存在 | 系统没有使用 LVM | 重新评估是否走物理分区扩容路径 |
| LVM 卷组显示没有空闲空间 | 物理卷没成功加入卷组 | 确认分区类型为 8e，重新执行vgextend |
| fdisk 只能识别 2TB 以下 | MBR 分区表限制 | 需要在 GPT 下操作，使用gdisk配合扩容 |
这里挑几个高频问题展开说一下。
第一个是设备忙的问题。只要分区处于 mounted 状态，内核不会允许重新读写它的分区表，这是为了保护数据一致性。如果操作的是根分区或者/var等关键路径，重启是几乎唯一的办法。如果是数据盘，可以先umount再执行partprobe，操作完再挂载回来。
第二个是 xfs_growfs 报 not found。Centos 7 最小化安装时可能没有装 xfsprogs，但奇怪的是系统却是 xfs 文件系统，这时候需要先装工具包。这个坑在精简安装的机器上很常见，提前装好能省去临场解决问题的麻烦。
第三个是 fstab 写错导致进不了系统，这个情况比较严重。如果启动时提示 "Failed to mount /data" 然后进入 emergency mode，输入 root 密码登录后，先以只读方式检查/etc/fstab：
mount -o remount,rw /然后用blkid检查实际 UUID，修正 fstab，执行mount -a验证，确认无误后重启即可恢复。千万不要在原系统盘 fstab 混乱的时候直接重启，那可能会让问题变得更复杂。
4.3 关于 swap 分区和数据盘挂载的特殊情况
扩容过程还可能遇到 swap 分区和数据盘两个特殊场景。
先说 swap。如果 swap 放在独立分区或独立逻辑卷上，想要扩大 swap 空间，流程和根分区扩容类似。如果是 swap 文件方式（Centos 7 之后常用），可以直接新建一个更大的 swap 文件切换掉旧的：
# 创建一个 4G 的 swap 文件 fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile为了让重启后依然生效，还需要在 fstab 中加一行：
/swapfile none swap defaults 0 0这种方法比调整分区方便很多，特别是遇到磁盘剩余空间分散在尾部、不方便划区的情况时。
再说数据盘。很多生产机器加装新磁盘后，系统已经能识别/dev/sdb，但需要手动分区、格式化、挂载。这套流程做完后，千万别忘了前面说的 fstab 配置。另外，如果数据盘走的是 LVM，可以直接vgextend到已有卷组，把新盘容量并进根分区所在卷组，再扩展逻辑卷，实现统一管理。这种方式比新增一个独立数据盘更利于后续容量调配。
关于 LVM 场景还有一个值得注意的点：vgextend加入的 PV 可以来自不同的物理磁盘，这也意味着只要 VG 里还有空间，LV 的扩展就不一定需要在同一块盘上进行。所以在虚拟化平台上扩容虚拟机硬盘后，先vgextend，再lvextend，步骤并不会有太多变化，无非是多了一次卷组扩展。
5. 分区扩容的规划建议与操作心得
5.1 不同磁盘管理方案怎么选
操作过几次扩容后，我对不同磁盘管理方案的使用场景有了比较清晰的认识。这里给准备做分区规划或者打算调整存储架构的朋友一些参考。
如果是刚接手一台旧机器，建议保持原有方案，尽量不跨方案迁移。比如原来是 LVM 就继续 LVM，原来是物理分区就继续物理分区，不要一边扩容一边想把物理分区改成 LVM，那等于重复踩坑两遍。
如果是新装系统，我是强烈推荐 LVM 方案的。Centos 安装时选择 "Automatically configure partitioning" 后再点 "I will configure partitioning"，然后在分区策略里选 LVM，创建卷组时留出一定的未分配空间。这样后续需要扩容时，只需要新加磁盘或者在虚拟化平台上扩大磁盘，再通过 pvcreate、vgextend、lvextend 三步搞定，不需要碰分区表，安全性高很多。
如果是云服务器，很多云厂商提供了在线扩容云盘的入口，控制台上扩完容量后，系统内的操作其实就是本文前面讲的那套流程。不同云厂商可能有一个 "扩展分区和文件系统" 的引导文档，但底层原理都是通用的，掌握了命令，切到任何一家的控制台都心里有底。
5.2 扩容操作顺序的黄金法则
所有扩容操作，我总结出一个"四步法则"：
- 先备份关键数据和分区表
- 再扩大底层（虚拟磁盘、物理磁盘、云盘）
- 然后扩大逻辑层（分区、PV、VG、LV）
- 最后扩大文件系统层（resize2fs 或 xfs_growfs）
这个顺序不能乱，一旦乱了，很容易出现"底层空间已经加了，但上层文件系统识别不到"的尴尬局面。
相反的顺序更是大忌，比如在磁盘本身没扩大的情况下，直接对文件系统执行resize2fs想扩大容量，那是不会成功的，因为文件系统大小不能超过分区大小，分区不能超过磁盘大小。每一层都有硬边界，上层容量必须小于等于下层容量，这个物理约束在任何存储架构下都成立。
还有个细节很多人不在乎：扩容操作尽量选在业务低峰期。虽然 xfs 和 ext4 都支持在线扩容，但在数据写入很频繁的时段执行，万一遇到断电或者 IO 错误，出现文件系统损坏的概率会显著增加。稳妥的办法是先sync同步一次缓存数据，再执行扩容命令，减少数据不一致的风险。
5.3 用 df 和 lsblk 联合验证扩容结果
扩容结束后，很多人习惯只看df -h，发现容量变了就完事。我的建议是要多花 10 秒做一次完整验证：
# 查看文件系统容量是否扩展成功 df -hT # 查看底层块设备和分区关系 lsblk # 查看逻辑卷容量变化 lvs三个命令交叉对比，基本可以确认扩容在每个层级都生效了。比如df -h显示根分区 95G，lsblk显示 sda 100G，lvs显示 root 逻辑卷 95G，这三个数字对得上，说明磁盘、分区、文件系统三个层级都同步了。
如果发现df显示容量依然偏小，先检查lsblk里磁盘总容量是否已经扩大，再检查分区大小是否同步，再检查逻辑卷大小，最后检查文件系统。逐层排查，定位是哪一层没扩散到位，再针对性地处理。
扩容完成后，还有一个容易被忽视的动作，就是用df -i查看 inode 使用率。有些场景下文件系统容量还有剩余，但 inode 不够了，也会导致无法创建新文件。扩容前如果 inode 已经接近上限，扩容时可以考虑重新调整 inode 数量策略，不过这属于比较高级的调优范畴，一般场景下默认值就够用。
最后分享一个小习惯：操作完任何分区有关的事情，我都会顺手把blkid的输出保存一份到本地，这样下次维护或者上线新的监控脚本时，随时能查到每个设备对应的 UUID，而不必重新扫描系统。这种小细节在故障处理和备份恢复时能省下不少时间，建议你也试试。
