接手一台跑了两年多的CentOS 7服务器，最常遇到的报警就是磁盘空间不足。尤其是那些部署了数据库、日志服务或者文件存储的业务，当初规划再精细，也架不住业务数据的持续增长。面对这种情况，如果服务器底层是虚拟机或者云主机，运维人员通常会直接调整虚拟磁盘的大小，然后在线将新增空间同步到操作系统内的分区和文件系统。整个过程无需重启，业务中断时间几乎为零。这里的关键技术点，就是LVM逻辑卷的在线扩容。
确认当前磁盘与LVM布局动手之前，必须把现有的存储架构看清楚。很多人拿到机器就直接敲扩容命令，结果发现新增的空间根本不在同一个卷组里，白费力气。先通过lsblk命令查看块设备关系：
lsblk
输出会清晰展示磁盘、分区以及它们之上的LVM逻辑卷。假设输出显示sda磁盘大小为200G，上面有sda1和sda2两个分区，其中sda2是LVM物理卷，归属于centos卷组，下面挂着root和home两个逻辑卷。现在需要把sda磁盘扩展到500G，新增的300G全部交给root逻辑卷使用。再通过vgdisplay和lvdisplay确认卷组剩余空间：
vgdisplay lvdisplay
vgdisplay输出中的Free PE / Size字段会告诉你卷组还有多少可用空间。如果这里显示为0，而磁盘确实已经扩容了，说明新增空间还处于未分配状态，需要后续步骤将其加入卷组。
刷新磁盘容量并创建新分区云平台或虚拟化层完成磁盘扩容后，操作系统不会自动识别新容量。对于SCSI类型的磁盘，需要手动触发内核重新扫描设备。执行以下命令：
echo 1 > /sys/class/block/sda/device/rescan
再次运行lsblk或fdisk -l /dev/sda，确认磁盘总容量已经变成500G。接下来需要在原有分区基础上，利用新增的300G空间创建一个新分区。使用fdisk进入交互模式：
fdisk /dev/sda
输入n创建新分区，分区号默认选择3，起始扇区直接回车使用默认值，结束扇区也直接回车以使用全部剩余空间。输入t修改分区类型，选择分区3，类型代码输入8e（Linux LVM）。最后输入w写入分区表并退出。如果系统提示分区表正在使用中，可能需要执行partprobe命令让内核重新加载分区表，或者直接重启服务器。但在生产环境中，partprobe通常能解决问题：
partprobe /dev/sda
lsblk再次确认，应该能看到sda3分区出现了，大小正好是300G。
将新分区初始化为物理卷并加入卷组新分区sda3现在只是一块裸盘区域，需要先标记为LVM物理卷。执行：
pvcreate /dev/sda3
创建成功后，使用vgextend将其加入到centos卷组：
vgextend centos /dev/sda3
此时再运行vgdisplay，Free PE / Size字段应该显示有300G可用空间了。这一步是整个扩容流程的桥梁，把底层磁盘的新增容量传递给了LVM管理层。
在线扩展逻辑卷有了空闲的卷组空间，就可以直接扩展root逻辑卷。假设要把300G全部加进去，使用lvextend命令：
lvextend -L +300G /dev/centos/root
也可以使用百分比形式，比如使用卷组100%的剩余空间：
lvextend -l +100%FREE /dev/centos/root
命令执行后，lvdisplay可以看到root逻辑卷的LV Size已经增加了。但此时df -h查看挂载点，容量并没有变化。这是因为逻辑卷的块设备虽然变大了，但上面的文件系统还没有感知到新边界。这是很多新手容易困惑的地方，也是扩容操作中最关键的一步区分点。
根据文件系统类型在线调整大小CentOS 7默认使用XFS文件系统，这也是目前企业级环境的主流选择。对于XFS文件系统，需要使用xfs_growfs命令来扩展。注意，XFS只能扩展不能收缩，而且扩展操作必须针对挂载点进行：
xfs_growfs /
如果逻辑卷挂载在根目录，直接指定斜杠即可。命令执行后，会输出data blocks changed信息，说明文件系统已经识别并占用了新增空间。df -h再次查看，根分区容量已经变成原来的大小加上300G。
如果某些老系统或者特定业务使用的是ext4文件系统，则需要使用resize2fs命令：
resize2fs /dev/centos/root
ext4同样支持在线扩容，但前提是内核版本和e2fsprogs工具包足够新。整个过程无需卸载分区，业务可以持续运行，这正是LVM在线调整的核心价值所在。
处理根分区特殊情况的注意事项当扩容对象是根分区时，有一点需要特别留意。根分区在系统启动初期就会被挂载，某些情况下内核可能不会立即更新对分区表的认知。如果执行partprobe后仍然看不到新分区，或者pvcreate提示设备不存在，可以尝试使用kpartx工具强制刷新，或者通过echo命令重新扫描整个磁盘设备。还有一种稳妥做法是在创建分区时，使用fdisk的额外选项确保分区表变更被正确写入。实际操作中，如果partprobe失败，重启是最保险的选择，但需要提前申请维护窗口。
另外，对于使用了GPT分区表的磁盘，fdisk同样可以处理，但操作界面略有不同。使用gdisk工具会更顺手。无论是MBR还是GPT，核心逻辑不变：新分区、做PV、加入VG、扩展LV、调整文件系统。
非LVM环境下的直接分区扩容并不是所有服务器都使用了LVM。有些传统部署或者极简安装直接使用标准分区。这种情况下，如果磁盘扩容了，操作会更加受限。传统分区扩容需要删除旧分区并创建新分区，且起始扇区必须完全一致，否则数据会丢失。整个过程风险极高，强烈建议先做全量数据备份。更可行的方案是使用growpart工具，它是cloud-utils包的一部分，能够自动处理分区表调整：
growpart /dev/sda 2
这条命令会将sda2分区扩展到磁盘末尾。之后同样需要执行xfs_growfs或resize2fs调整文件系统。但growpart的可靠性依赖于具体环境，生产操作前务必在测试机验证。总体而言，LVM提供了更灵活、更安全的扩容路径，这也是为什么现代Linux发行版默认推荐LVM布局的原因。
扩容后的验证与监控操作完成不代表万事大吉。立即通过df -h确认挂载点容量变化，通过lvdisplay确认逻辑卷边界，通过vgdisplay确认卷组剩余空间归零或符合预期。同时，观察业务日志和服务状态，确保没有因为IO抖动导致异常。建议在扩容前后各执行一次iostat -x 1 10，对比磁盘IO指标是否有明显波动。正常情况下，在线扩容对业务的影响微乎其微，但监控数据能给你和团队提供确凿的安心依据。
最后，把这次操作步骤记录下来，包括磁盘布局、执行的命令序列、前后容量对比，更新到运维文档或知识库。下次再遇到类似情况，无论是自己操作还是同事接手，都能快速定位执行，减少排错时间。磁盘扩容虽然是基础操作，但细节决定成败，尤其是分区表重载和文件系统扩展这两个环节，稍有疏忽就可能导致数据不可用。掌握LVM在线调整这套组合拳，日常运维中至少80%的磁盘空间问题都能从容应对。
