当云服务器（云端虚拟计算资源）的系统盘或数据盘容量不够时，控制台里点一次“扩容”通常只完成了第一半：底层块设备变大了，但 Linux 里的分区、LVM（逻辑卷管理器）和文件系统不一定自动变大。本文会解决这个断点，教你如何在线确认磁盘新容量、扩展 LVM（逻辑卷管理器）以及让 ext4 或 XFS 文件系统真正可用，尽量减少业务停机时间。
扩容前先把目标说清楚：我们不是“盲目执行 resize 命令”，而是沿着“块设备 → 分区或物理卷 → 卷组 → 逻辑卷 → 文件系统”的链路逐层确认。这样做的好处是，一旦某一步没有变化，你能马上知道卡在设备识别、分区边界还是文件系统层，而不是等到线上写入失败才排查。
先判断当前磁盘结构，别直接扩容文件系统
开始操作前，建议先记录三类信息：挂载点使用率、块设备关系和文件系统类型。尤其是生产环境中的网站目录、数据库目录、日志目录，扩容对象可能不是根分区，而是单独挂载的数据卷。如果你还在评估主机规格和磁盘策略，可以先参考 Hostease 的 服务器配置相关文章，把容量、备份和增长周期一起规划。
df -hT lsblk -f sudo pvs sudo vgs sudo lvs
df -hT 用来确认挂载点、容量和文件系统类型；lsblk -f 能看到磁盘、分区、LVM（逻辑卷管理器）与挂载点的层级；pvs/vgs/lvs 则分别确认物理卷、卷组和逻辑卷。把这些输出保存到变更记录里，后续验证时就有对照基准。
常见结构有两种。第一种是 /dev/vda1 这类普通分区直接挂载到 / 或 /data，这种场景通常只需要扩展分区和文件系统。第二种是 /dev/vda3 作为 LVM（逻辑卷管理器）物理卷，下面再分出 /dev/mapper/vg-root、/dev/mapper/vg-data 等逻辑卷；这时必须先让物理卷识别新空间，再扩展逻辑卷。
让系统识别新增容量，并确认分区是否需要增长
控制台完成磁盘扩容后，Linux 内核有时不会立即看到新容量。你可以先用 lsblk 或 blockdev 查看磁盘大小。如果仍然是旧容量，优先执行重新扫描；不同发行版路径略有差异，下面以常见 virtio 磁盘为例。
lsblk sudo blockdev --getsize64 /dev/vda echo 1 | sudo tee /sys/class/block/vda/device/rescan lsblk
如果 lsblk 中整块磁盘已经变大，但分区仍然保持旧大小，就需要扩展分区边界。很多 Linux 镜像自带 growpart，它适合把已有分区扩展到磁盘尾部。例如根分区在 /dev/vda3 时，命令是对磁盘 /dev/vda 的第 3 个分区执行增长。
sudo growpart /dev/vda 3 lsblk
这里不要把 /dev/vda3 误写成命令参数的第一个位置。growpart /dev/vda 3 表示“扩展 /dev/vda 上的第 3 个分区”。如果你使用的是 GPT 分区表，扩容后可能看到备份分区表不在磁盘末尾的提示，通常可以按工具建议修复后再继续。涉及网站迁移或容量规划时，也可以结合 网站性能与资源优化文章 判断是否需要同步优化缓存和日志策略。
扩展 LVM 物理卷、逻辑卷和文件系统
当分区边界已经变大，下一步是让 LVM（逻辑卷管理器）物理卷识别新空间。假设物理卷是 /dev/vda3，可以执行 pvresize，再用 vgs 查看卷组中的空闲容量。这个步骤不会自动扩大具体挂载点，它只是把新增空间加入可分配池。
sudo pvresize /dev/vda3 sudo vgs sudo pvs
接下来扩展目标逻辑卷。若你希望把卷组剩余空间全部给根分区，可以使用 -l +100%FREE；如果只增加 50G，则使用 -L +50G。生产环境更推荐按业务增长周期分配，例如先增加 50G，保留部分空间给日志卷或数据库卷。
sudo lvextend -l +100%FREE /dev/mapper/vg-root 或者执行：sudo lvextend -L +50G /dev/mapper/vg-root
逻辑卷变大后，还要扩展文件系统。ext4 使用 resize2fs，XFS 使用 xfs_growfs，并且 XFS 的参数通常是挂载点而不是块设备。先用 df -hT 确认类型，再选择命令。
df -hT / sudo resize2fs /dev/mapper/vg-root 如果是 XFS，执行：sudo xfs_growfs / df -hT /
也可以把逻辑卷和文件系统扩展合并为一步：lvextend -r 会调用合适的文件系统增长工具。它很方便，但不适合你还没确认文件系统类型、挂载点和备份状态的场景。第一次处理线上扩容时，我们建议分步执行，便于定位问题。
普通分区没有 LVM 时，扩容路径更短
不是所有环境都用了 LVM（逻辑卷管理器）。如果 lsblk -f 显示 /dev/vdb1 直接挂载为 /data，没有 LVM2_member，流程就变成：识别磁盘新容量、扩展分区、扩展文件系统。它步骤少，但容错空间也更小，因为没有卷组可做二次分配。
sudo growpart /dev/vdb 1 sudo resize2fs /dev/vdb1 如果 /data 是 XFS，执行：sudo xfs_growfs /data df -hT /data
这里要特别留意挂载点。不要看到 /dev/vdb1 就默认它是数据目录，必须用 findmnt /data 或 lsblk -f 再确认一次。若你运行的是业务站点，扩容前还应检查备份策略；可参考 WordPress 运维与备份相关文章，把应用层备份和磁盘层扩容分开处理。
扩容后的验证和风险控制
扩容完成不等于变更结束。至少要验证挂载点容量、读写能力、系统日志和业务服务状态。下面这组命令适合放进变更单的收尾检查中，能覆盖“容量显示正常但目录不可写”这类低级问题。
df -hT lsblk -f sudo lvs sudo dmesg | tail -n 30 touch /data/.resize-test && rm -f /data/.resize-test
如果是数据库、图片存储或备份目录，还建议观察 10 到 30 分钟的写入趋势。日志目录扩容后，要确认 logrotate 规则没有因为路径变化失效；数据库目录扩容后，要确认实例没有残留只读或磁盘满导致的异常状态。对于增长较快的网站，选择支持平滑扩容的 VPS（虚拟专用服务器）主机 或弹性计算方案，会比频繁迁移整站更稳妥。
操作前的风险控制可以压缩成 4 个检查点：
- 备份：确认关键数据已有最近一次可恢复备份，例如数据库 dump、站点文件包或快照。
- 对象：确认扩容的是目标挂载点对应的磁盘，不只看设备名，要看
findmnt与lsblk。 - 工具：确认系统已安装
cloud-utils-growpart、lvm2、xfsprogs等必要组件。 - 窗口：即使是在线扩容，也建议放在低峰期，并提前准备回滚说明。
常见错误与排查思路
最常见的错误是只扩了控制台容量，却没有扩展分区或物理卷。表现为控制台显示 200G，系统里 df -h 仍是 100G。此时不要重复购买或再次扩容，而应沿着 lsblk → growpart → pvresize → lvextend → resize2fs/xfs_growfs 的顺序定位是哪一层没有变化。
第二类错误是把 ext4 和 XFS 命令混用。resize2fs 不能处理 XFS，xfs_growfs 又需要挂载点。执行前用 df -hT 看清文件系统类型，可以避免很多无效尝试。第三类错误是把所有空闲空间一次性分给根分区，导致后续数据卷、备份卷没有余量；如果你管理多业务站点，可以结合 虚拟主机（共享式网站托管） 与独立资源方案的边界，重新评估是否需要拆分服务和目录。
总结：把扩容当成一次可验证的链路变更
云服务器（云端虚拟计算资源）磁盘扩容的关键，不在某一个命令，而在确认每一层都接住了新增容量：块设备变大、分区变大、LVM（逻辑卷管理器）物理卷变大、逻辑卷变大，最后文件系统变大。只要按这个顺序执行，并在每一步用 lsblk、vgs、lvs、df -hT 验证，在线扩容通常可以做到可控、可追踪。
如果你需要给生产网站扩容，建议先在测试机复刻一次流程，记录实际设备名和挂载点，再安排低峰变更窗口。对于容量增长稳定、希望减少迁移成本的站点，可以考虑选择支持后续资源升级的主机方案；如果目录结构复杂或涉及数据库，推荐先完成备份和恢复演练，再进行正式扩容。