分区已扩大但df容量未变，如何核查Linux云服务器扩容后的文件系统？

云服务器磁盘扩容后，lsblk 已显示分区变大，但 df -h 仍显示原来的容量，这通常意味着：内核识别到了更大的块设备，文件系统却还没有使用新增空间。另一种常见情况是，扩容的是某个数据分区，检查的却是根目录、其他挂载点，或者分区与文件系统之间还有一层未扩大的 LVM 逻辑卷。

核查时不能只比较两条命令的数字。应沿着“云盘 → 内核磁盘设备 → 分区 → 可选的 LVM → 文件系统 → 实际挂载路径”逐层确认，找到第一个容量没有增长的位置，再决定是否执行扩容命令。分区变大不等于文件系统变大；df 展示的是指定路径所在文件系统的容量，而不是云盘或分区容量。

一、确认现象：df 检查的究竟是哪一个文件系统

先从业务路径反查设备

以下以数据目录 /data、磁盘 /dev/vdb、分区 /dev/vdb1 为示例。它们只是说明排查路径，执行时必须替换为服务器上的真实对象。若扩容的是根文件系统，把路径改成 /，不要照搬数据盘名称。

先运行只读命令：

df -hT /data
findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINT

三条命令分别回答不同问题：

• df -hT /data：这个路径所在的文件系统有多大，类型是什么。
• findmnt -T /data：这个路径实际落在哪个挂载点，挂载源是什么，是否只读。
• lsblk：挂载源往外对应哪个分区、逻辑卷和磁盘。

例如，下面是一组示意输出：

$ df -hT /data
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vdb1      ext4   59G   42G   14G  76% /data

$ lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINT
NAME   PATH       TYPE  SIZE FSTYPE MOUNTPOINT
vdb    /dev/vdb    disk  120G
└─vdb1 /dev/vdb1   part  120G ext4   /data

这里，分区已接近 120 GiB，而 ext4 文件系统仍约 59 GiB，才符合“分区已扩大但 df 未变”的典型特征。

如果 findmnt 显示 /data 实际属于根文件系统，则可能是数据盘没有挂载，业务数据写进了根目录下的普通目录。此时应先核查挂载状态和数据位置，不能直接把数据盘挂载到 /data：挂载会遮蔽目录中已有文件，容易造成“文件突然不见了”的误判。

如果挂载源是 overlay、网络文件系统或其他非本机块设备，应转到其实际存储后端排查。尤其是在容器内执行 df 时，应回到宿主机确认存储映射，而不是对容器看到的路径盲目运行文件系统扩容命令。

排除单位和检查对象造成的误差

云平台显示的 GB 与 Linux 工具显示的容量可能采用不同口径：

• 十进制 1 GB = 1,000,000,000 字节。
• 二进制 1 GiB = 1,073,741,824 字节。
• df -h 通常按 1024 进制换算，但输出后缀显示为 G。

因此，100 GB 约等于 93.13 GiB，不能仅凭这类差异判断扩容失败。需要精确比较时，可查看字节数：

lsblk -b -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINT
df -B1 /data

即使文件系统成功扩大，df 的总容量也不必与分区字节数完全相同，文件系统元数据会占用空间。ext4 的保留块还会影响普通用户可用容量。真正需要定位的是“仍停留在扩容前的量级”，而不是几百 MiB 或少量百分比的差异。

把只读核查与写入操作分开

前面的命令只读取状态。后续涉及分区、PV、LV 或文件系统元数据写入，执行前应满足以下条件：

1. 已确认磁盘、分区、逻辑卷和挂载点的对应关系。
2. 已有可恢复的备份或云盘快照，并了解恢复范围；数据库等业务还需考虑应用一致性。
3. 没有正在运行的其他扩容、快照恢复或存储迁移任务。
4. 已安排必要的维护窗口，并具备云控制台或其他故障恢复入口。

在线扩容允许在特定条件下保持挂载，但不代表无风险。扩容通常没有简单的反向回滚：不能通过把磁盘或分区缩回原容量来撤销文件系统扩容。发生异常时应停止后续写入，根据备份恢复数据或恢复整条存储链。

二、由外到内：核对磁盘、分区表与内核视图

云平台已扩大，内核是否识别到新磁盘容量

在确认目标磁盘是 /dev/vdb 后，执行：

sudo blockdev --getsize64 /dev/vdb
lsblk -b -o NAME,TYPE,SIZE /dev/vdb

blockdev --getsize64 返回内核当前识别的设备大小，单位为字节。

如果云控制台显示磁盘已扩容，这里仍是旧容量，问题还没有到文件系统层。应先确认：

• 扩容任务是否完成，而非仅提交成功。
• 操作的是当前实例挂载的那块云盘。
• 客体系统是否需要重新扫描设备或重启才能识别变更。

不同云平台、虚拟磁盘驱动和设备类型的重新扫描方式不同，不应把某个 SCSI 扫描命令当作所有服务器的通用操作。按平台与驱动要求处理；如需重启，应先确认业务窗口、自动挂载配置和控制台登录能力。内核磁盘容量没有更新之前，运行 resize2fs 或 xfs_growfs 不会凭空产生空间。

分区表变大，不代表内核分区设备一定变大

继续读取磁盘上的分区表和内核中的分区设备容量：

sudo fdisk -l /dev/vdb
sudo blockdev --getsize64 /dev/vdb1
lsblk -b -o NAME,TYPE,SIZE /dev/vdb

这里需要区分两种视图：

• fdisk -l 读取磁盘分区表中的起止位置。
• blockdev --getsize64 /dev/vdb1 查询内核当前提供的分区设备大小。

如果分区表已经扩大，而内核中的 /dev/vdb1 仍是旧容量，文件系统扩容工具能使用的仍然是旧边界。这种情况常见于分区表已写入，但内核未成功更新正在使用的分区。

如果分区表和内核分区设备都仍是旧容量，则是分区未扩容，而非文件系统未扩容。

只有分区确实未扩大时，才进入分区操作分支

若只是核查“分区已扩大”的现象，可以跳过这一步。确需扩分区时，先确认该分区后方存在连续空闲空间。前面有未分配空间，或后面隔着其他分区，都不能通过简单增长解决。

先保存分区表记录。备份目录应位于目标盘之外，并及时复制到服务器外：

sudo sfdisk --dump /dev/vdb > /备份目录/vdb-partition-table.txt

这份文本便于追溯原布局，但不是数据备份，也不是扩容后可以直接覆盖回去的通用回滚文件。

若系统已安装 growpart，可先做预演：

command -v growpart
sudo growpart -N /dev/vdb 1

注意参数是“磁盘路径”和“分区号”，不是把 /dev/vdb1 作为整个磁盘传入。预演应显示原分区起始位置保持不变，结束位置增大；它不修改分区表。

确认目标正确、已有备份且后方连续空间可用后，才执行实际增长：

sudo growpart /dev/vdb 1

该命令会修改目标磁盘的分区表，不适用于需要移动其他分区的布局。出现 NOCHANGE 时，应检查是否已占满可用空间、剩余空间是否过小，或是否受分区表布局限制，不要反复执行。

如果磁盘上的分区表已经变大，但内核仍使用旧边界，可在维护安排下尝试让内核重新读取：

sudo partprobe /dev/vdb
sudo blockdev --getsize64 /dev/vdb1

partprobe 会请求内核更新分区信息，是否能成功取决于设备占用和内核支持。若报告设备忙、无法通知内核，或查询结果仍旧，不要继续尝试强制卸载根分区；按平台要求安排受控重启，再重新核对容量。

三、定位断点：是否存在未扩大的 LVM 层

看见更大的分区，也要确认文件系统是否直接位于其上

直接分区文件系统的链路通常是：

/dev/vdb → /dev/vdb1 → ext4 或 XFS → /data

LVM 场景则多出几层：

磁盘 → 分区 → PV → VG → LV → 文件系统 → 挂载点

如果 lsblk 中出现 LVM2_member，或者 findmnt 的挂载源是 /dev/mapper/...，不能把分区路径直接交给文件系统扩容工具。

常规 LVM 场景可先运行：

sudo pvs -o pv_name,pv_size,pv_free,vg_name
sudo vgs -o vg_name,vg_size,vg_free
sudo lvs -o lv_path,lv_size,segtype,devices

输出含义分别是：

• PSize：LVM 已识别的 PV 容量。
• PFree：该 PV 尚未分配的空间。
• VFree：卷组中可供逻辑卷使用的空间。
• LSize：目标逻辑卷提供给文件系统的容量。
• segtype：逻辑卷类型，帮助识别普通卷、精简卷、条带卷等差异。

如果分区已扩大但 PSize 未变，断点在 PV；如果 PV 已扩大、VG 有空闲，但目标 LSize 未变，断点在 LV；只有 LV 也变大后，才继续检查文件系统。

精简池、LVM RAID、加密映射和软件 RAID 不应套用普通线性 LV 的操作链。特别是精简卷，虚拟容量变大并不代表精简池已有足够的真实空间，应额外检查池的使用率与扩容条件。

用一张表判断下一步

修复应从第一个没有增长的层开始，而不是把所有扩容命令依次执行一遍。如果下层容量已经足够，就没有理由重复改分区表。

常规 LVM 的受控扩容

以下仅适用于已确认的普通 LVM 布局。操作会修改 LVM 元数据和容量分配；执行前应备份数据及 LVM 配置：

sudo vgcfgbackup

默认备份通常保存在本机 /etc/lvm/backup 下，应复制到服务器外。它记录 LVM 元数据，不包含文件内容。

如果确认 /dev/vdb1 是需要扩大的 PV：

sudo pvresize /dev/vdb1
sudo pvs -o pv_name,pv_size,pv_free,vg_name
sudo vgs -o vg_name,vg_size,vg_free

预期是 PSize 增大，卷组空闲空间增加。若没有变化，重新核查分区设备大小及 PV 对象；如果 PV 本来直接建在整块磁盘上，就应使用实际 PV 路径，而不是凭空增加分区号。

随后，若 VG 空闲至少 40 GiB，且计划为目标 LV 增加 40 GiB，可执行：

sudo lvextend -L +40G /dev/vgdata/lvdata
sudo lvs -o lv_path,lv_size

这里的卷组名和逻辑卷名均为示例，+40G 表示增加 40 GiB，不是把最终容量设为 40 GiB。选择明确增量，也能避免把共享卷组的全部空闲空间分给一个业务。

为便于排障，这里不使用自动联动文件系统扩容的参数，而是先验证 LV，再单独扩大文件系统。LV 一旦扩容并被文件系统使用，不应通过缩小 LV 撤销；异常时停止后续操作，按照已准备的恢复方案处理。

四、修复文件系统：ext4 与 XFS 分别执行

操作前再确认类型、源设备和挂载状态

进入文件系统层之前，再核对一次：

findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /data

只有以下条件同时成立，才适合继续：

• 文件系统类型和准备使用的工具匹配。
• 挂载源是刚刚核实过的分区或 LV。
• 下层设备已经具备新增容量。
• 系统没有明显的 I/O 错误或文件系统损坏迹象。

可读取近期内核日志辅助判断：

sudo dmesg -T | tail -n 100

如果出现存储 I/O 错误、ext4 错误、XFS 元数据损坏或文件系统被强制转为只读，应先处理健康问题，不要用扩容掩盖故障。dmesg -T 的时间显示适合辅助定位，不应单独作为严格的故障时间证据。

ext4：扩大实际承载文件系统的设备

对于直接建在 /dev/vdb1 上的 ext4，可先读取超级块信息：

sudo tune2fs -l /dev/vdb1 | grep -E 'Block count:|Block size:|Filesystem features:|Filesystem state:'

“块数量 × 块大小”可用于估算文件系统当前规模。例如，16,777,216 个块、每块 4096 字节，对应 68,719,476,736 字节，即 64 GiB。这是文件系统块空间，不等同于 df 显示的普通用户可用空间。

确认备份可用、下层容量已增加、内核和 ext4 特性支持在线增长后，可执行：

sudo resize2fs /dev/vdb1

不指定大小时，resize2fs 尝试增长到该设备可用的容量。若 ext4 位于 LVM 上，参数应改为实际 LV：

sudo resize2fs /dev/vgdata/lvdata

这两条是不同布局下的替代命令，不是需要连续执行的步骤。

如果提示 Nothing to do，表示工具认为当前文件系统已达到该设备能够提供的大小，应回查设备是否选对、内核是否仍看到旧容量，以及 df 是否检查了正确路径。

如果提示需要文件系统检查，或当前环境不支持在线增长，应进入离线维护。不要对仍挂载的 ext4 运行修复型文件系统检查。根文件系统通常需要救援环境；数据文件系统也必须先停业务，并确认没有残留挂载、绑定挂载或其他使用者，再按工具提示安排检查与扩容。

不要运行 mkfs 来“刷新容量”。格式化是重建文件系统，会破坏已有数据，与在线增长不是同一种操作。

XFS：对挂载点增长，而不是照搬 ext4 命令

XFS 使用不同工具，先检查几何信息：

sudo xfs_info /data

重点看数据区域的 bsize 和 blocks，它们反映文件系统数据区规模；不要把日志区域参数当成总容量。

确认 /data 是目标 XFS 挂载点、挂载为可写状态、下层设备已扩大且文件系统健康后，执行：

sudo xfs_growfs -d /data

-d 表示增长数据区到当前下层设备允许的容量。XFS 的常规增长要求文件系统处于挂载状态，参数应使用核实过的挂载点，而不是机械替换为 /dev/vdb1。

若提示目标不是已挂载的 XFS 文件系统，回查 findmnt；若提示数据大小未变化，则重点检查下层设备容量。不要改用 resize2fs 尝试处理 XFS。

XFS 扩容同样会写入文件系统元数据，应有备份。不要把“缩回原容量”作为它的常规回滚方案。

如果识别到的类型不是 ext4 或 XFS，应使用该文件系统自身的容量管理方式。Btrfs 等文件系统可能涉及多设备或不同分配机制，不能照搬以上命令。

五、修复后复测：容量变化与业务恢复要分别验收

先验证存储链，再验证 df

扩容命令结束后，重复执行最初的只读检查：

findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -b -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINT
df -B1 /data
df -hT /data
df -i /data

有 LVM 的服务器还应复查 PV、VG 和 LV。验收时看四件事：

1. 对象一致：挂载源仍是预期分区或逻辑卷，没有检查错路径。
2. 链路增长：磁盘、分区、必要的 LVM 层及文件系统都达到计划容量。
3. 状态正常：挂载未意外变为只读，日志没有新增相关错误。
4. 资源够用：不仅块空间恢复，inode 也没有耗尽。

不必要求每层数字完全相等。分区边界、LVM 对齐与文件系统元数据都会带来合理差异；应记录每一层的实际值，并解释差异来源。

df 已增长，但业务仍写不进去

如果总容量已经变化，业务仍报 No space left on device，问题可能已不属于扩容未生效。接下来应检查：

• 业务实际写入的路径是否位于目标文件系统。
• df -i 是否显示 inode 耗尽。
• 用户、组或项目配额是否限制了可用空间。
• 文件系统是否只读，或业务进程缺少目录写入权限。
• ext4 保留空间是否影响非特权进程可用容量。
• 是否有已删除但仍被进程打开的大文件。

需要核查最后一种情况时，若已安装 lsof，可运行：

sudo lsof +L1

它是只读诊断，不会释放空间。大型服务器上输出可能较多，应按挂载点、路径和进程归属继续筛查。发现占用后，协调应用正常关闭文件或按维护流程处理，不要直接终止不明进程。

df 与 du 的统计对象也不同：前者查看文件系统空间分配，后者遍历可见目录。因此两者不完全一致，不能直接说明扩容失败。

六、持续观察：保留容量基线与异常信号

完成扩容后，保留扩容前后的 df、lsblk、findmnt 输出；有 LVM 的环境同时保留 pvs、vgs、lvs 结果，以及操作时间和备份位置。这些记录可以帮助下一次扩容区分“磁盘没识别”“中间层没增长”和“文件系统没增长”，避免重复修改已经正确的层。

随后观察业务日志、磁盘使用率、inode 使用率、I/O 错误和文件系统只读告警。若数据写入较快，还要确认新增空间的消耗速度符合预期，而不是被异常日志或临时文件迅速占满。

最终验收标准应是：目标路径映射正确，各层容量衔接正常，文件系统总量已增长，业务能在其权限范围内正常写入，且观察期内没有新增存储错误。如果仍然只是 lsblk 变大而 df 不变，就回到实际挂载源沿链路逐层比较；不要跳过中间层，更不要把格式化当成扩容补救。

围绕Linux业务的数据增长与存储承载需求，A5数据提供采用SSD、NVMe及大容量机械硬盘的物理服务器方案。香港、美国的NVMe配置结合不同档位的CPU与内存，为数据库、业务后台和容器应用提供计算与存储基础；香港存储系列及日本CTG的大容量HDD方案，则可承载业务文件、备份数据与归档内容，覆盖活跃数据处理和长期数据留存等不同场景。