橙心橙怡1. "虚拟机加了磁盘容量，进到系统怎么没变化"——问题背后的两层真相
先说一个我见过无数遍的场景：运维或开发同学在虚拟化平台（VMware、Proxmox VE、KVM，甚至云控制台）里给虚拟机加了100G硬盘，回到系统里敲df -h，发现根分区还是原来的大小。于是开始怀疑平台操作没生效、怀疑自己加错了机器，甚至直接提工单。其实虚拟机平台那边大概率没做错，问题出在"系统里看到的磁盘"和"虚拟机分配的磁盘"根本不是一个层面的东西。
这里必须把两个概念拆开：块设备大小和文件系统大小。虚拟机平台增加的是虚拟磁盘文件（或者说控制器暴露给客户机的SCSI/SATA设备）的容量，对应到Linux里是/dev/sda、/dev/vda、/dev/nvme0n1这类块设备。而df -h显示的是文件系统的大小，文件系统建立在分区（/dev/sda1、/dev/vda2）之上，分区又建立在块设备之上。三层各管各的账：
- 块设备层：
lsblk看到的大小，对应虚拟磁盘总量； - 分区层：
fdisk -l看到的分区大小，分区表里记录着每个分区的起止扇区； - 文件系统层：
df -h看到的大小，文件系统在被分区划定的空间里自行管理元数据和数据块。
虚拟机扩容只动了第一层的账本，后面两层完全不知道有新空间可用。所以"加了容量没变化"不是玄学，而是你还没有把新增的空间逐层"认领"下来。这个过程在Linux社区里叫"在线扩容"（online resizing）或者"热扩容"，核心操作就是三步：让分区表识别新空间、让分区/逻辑卷使用新空间、让文件系统扩展到新空间。缺任何一步，df -h都不会有变化。
我遇到很多朋友栽在另一个心智模型上：以为扩容和格式化一样是"一步到位"的。实际上Linux存储栈是分层设计的，这种分层带来了极大的灵活性，但也让扩容变成一件必须按顺序做对每层的事。在往下讲具体操作之前，先把整套体系搞清楚，后面才不会出乱子。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手扩容前的准备：先搞清楚你手上是哪一套磁盘体系
同样一句话"给磁盘扩容"，在不同机器上的做法天差地别。我见过有人在LVM卷组上折腾半天growpart，也见过有人拿着resize2fs硬怼XFS文件系统然后报错。所以动手前第一件事不是敲命令，而是搞清楚你面对的是哪种存储布局。
2.1 三种常见的磁盘体系，扩容路径完全不同
第一种，LVM逻辑卷管理。 这是目前Linux服务器上最常见的方案，尤其是RHEL/CentOS系默认安装就会把根分区放在LVM里。LVM的层级是：物理卷（PV）→ 卷组（VG）→ 逻辑卷（LV）→ 文件系统。扩容路径是：块设备 → PV → VG → LV → 文件系统，比普通分区多两层，但好处是可以在线操作，几乎不用重启。这也是我要重点讲的一种。
第二种，普通分区（非LVM）。 直接用fdisk或gdisk在磁盘上划分分区，然后在分区上格式化。传统MBR磁盘只用fdisk，GPT磁盘用gdisk或parted。这种布局扩容最麻烦的地方在于：如果扩展的是最后一个分区，还有戏；如果新空间在中间或者后面还有其他分区占着，往往需要移动分区，风险和复杂度都很高。
第三种，云盘/整盘直通。 在AWS、阿里云这类云平台上，块存储设备经常使用NVMe或virtio接口，分区方式和前两种类似，但云平台通常有配套的扩容命令（比如AWS的growpart加resize2fs组合）。本质上还是分区和文件系统层面的操作，原理一样。
判断方法很简单：跑一个lsblk -f，如果看到sda下面有sda2，而sda2的挂载点是/，同时pvs命令能输出物理卷信息，那基本就是LVM体系。
2.2 扩容前必须做的三件事
第一，打快照或备份。这不只是"保险起见"，而是扩容操作虽然理论上是安全的，但growpart修改分区表时如果碰到内核分区表被占用（busy），或者断电、会话中断，分区表损坏的后果是灾难性的。虚拟机平台提供磁盘快照是最省事的，没有快照能力的话至少tar或rsync备份关键数据。
第二，确认分区表类型。fdisk -l输出里能看到"Disklabel type: gpt"或"dos"（MBR）。MBR分区扩容在2TB以上有天然限制，GPT则没有这问题。另一个关键点是：LVM的物理卷在MBR磁盘上通常使用8e分区类型，在GPT上用8e00，如果分区类型不对，LVM识别不到。
第三，确认文件系统类型。在lsblk -f的FSTYPE列里能看到xfs、ext4或btrfs。这一步直接决定扩容用哪个命令：ext4用resize2fs，XFS用xfs_growfs，Btrfs用`btrf