LVM扩容后根分区未变大怎么办？香港服务器系统盘检查与回滚方法

LVM扩容后，如果 lsblk 显示磁盘容量变大，但 df -h / 中的根分区仍然没有变化，通常不是扩容失败，而是扩容只完成了某一层。标准链路是“磁盘 → 分区 → LVM PV → VG → LV → 文件系统 → /”，其中任意一层没有继续扩展，根分区都不会获得可用空间。一般不需要重装香港服务器系统，先找出容量停留在哪一层，再从该层继续操作。

建议先不要重复执行 lvextend，也不要直接格式化或使用 lvreduce。先保存当前状态，确认根分区的文件系统类型、LV路径和底层设备；扩展文件系统后通常不能用简单命令安全缩回，真正的回滚依赖扩容所处阶段、备份或快照。

先确认根分区实际对应关系

识别根文件系统和LVM层级

以下命令适用于常见的 Debian、Ubuntu、Rocky Linux、AlmaLinux、CentOS 等使用 systemd 和 LVM 的环境。建议使用 root 执行，或在命令前添加 sudo。

findmnt -no SOURCE,FSTYPE,TARGET /
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
vgs -o vg_name,vg_size,vg_free
lvs -a -o lv_path,vg_name,lv_name,lv_size,lv_attr,segtype,data_percent,metadata_percent
df -hT /
df -ih /

典型的标准结构类似下面这样：

/dev/vda
└─/dev/vda3                 100G  part
  └─LVM PV                  100G
    └─VG vg0                100G
      └─LV /dev/vg0/root     40G
        └─ext4              mounted on /

也可能看到设备名为 /dev/nvme0n1p3、/dev/mapper/vg0-root，名称不同并不影响判断。重点是确认：

• 磁盘总容量是否已经变大；
• 承载LVM的分区是否已经扩展到磁盘末端；
• PV是否识别到了新增空间；
• VG中是否出现可用空间；
• 根LV是否已经变大；
• 文件系统是否已经执行扩容。

如果 findmnt 显示的根设备不是LVM，例如 /dev/vda2，则不能直接套用 pvresize 和 lvextend。如果中间出现 crypt、md、RAID或其他存储层，也应先确认完整链路，再决定扩容顺序。

先保存扩容前后的证据

在继续操作前，记录时间、设备关系和容量状态。这样既便于确认哪一层发生变化，也方便出现异常时提供给运维人员或服务商。

mkdir -p /root/lvm-check
{
    date -Is
    echo '--- root mapping ---'
    findmnt -no SOURCE,FSTYPE,OPTIONS,TARGET /
    echo '--- block devices ---'
    lsblk -o NAME,TYPE,SIZE,START,FSTYPE,MOUNTPOINTS
    echo '--- physical volumes ---'
    pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
    echo '--- volume groups ---'
    vgs -o vg_name,vg_size,vg_free
    echo '--- logical volumes ---'
    lvs -a -o lv_path,vg_name,lv_name,lv_size,lv_attr,segtype,data_percent,metadata_percent
    echo '--- filesystem usage ---'
    df -hT /
    df -ih /
} 2>&1 | tee "/root/lvm-check/before-$(date +%F-%H%M%S).txt"

输出中可能包含主机名、设备名称或挂载路径。对外提交前应检查并遮盖不需要公开的信息。

按层排查：找出容量停留的位置

第一层：系统是否识别到了新增磁盘容量

先查看块设备大小：

lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,MOUNTPOINTS
blockdev --getsize64 /dev/vda

这里的 /dev/vda 只是示例，必须替换成实际系统盘。若系统盘是 NVMe，可能是 /dev/nvme0n1。

判断方式如下：

如果服务器刚完成云平台或虚拟化平台侧的磁盘扩容，而 lsblk 仍显示旧容量，可以尝试重新扫描SCSI设备。仅在确认实际设备是 /dev/vda、且对应路径存在时使用：

test -e /sys/class/block/vda/device/rescan && \
echo 1 > /sys/class/block/vda/device/rescan

udevadm settle
lsblk -o NAME,TYPE,SIZE,MOUNTPOINTS

如果路径不存在，不要为了“刷新容量”随意向其他设备写入。部分NVMe、硬件RAID或特殊虚拟磁盘的重新扫描方式不同，远程操作时应通过服务商控制台或维护环境确认。SSH连接不稳定时，最好先准备带外控制台，避免分区表刷新或重启后无法登录。

第二层：磁盘变大但LVM分区没变

假设检查结果如下：

NAME   TYPE  SIZE MOUNTPOINTS
vda    disk  200G
├─vda1 part    1G /boot
└─vda3 part   80G

如果 pvs 显示PV位于 /dev/vda3，说明磁盘已经有200G，但LVM分区仍只有80G。常见系统可以使用 growpart 扩展分区：

growpart /dev/vda 3
partprobe /dev/vda
udevadm settle
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

NVMe设备的语法不同，例如：

growpart /dev/nvme0n1 3
partprobe /dev/nvme0n1
udevadm settle

growpart 的第一个参数是整块磁盘，第二个参数是分区编号，不是分区设备路径。不能把 /dev/vda3 直接作为第一个参数，也不能只凭“通常是第3分区”就执行，必须以 lsblk 和 pvs 的实际结果为准。

如果系统没有 growpart，不要立即使用交互式分区工具删除并重建分区。删除分区再重建，即使起始扇区填写正确，也存在输入错误和分区表损坏风险。可以先确认系统发行版、分区表类型和分区起止位置：

parted -s /dev/vda unit GiB print free

分区调整前应至少具备以下条件：

• 已完成重要数据备份或平台级磁盘快照；
• 已记录原分区的起始扇区和结束位置；
• 已确认目标分区确实是LVM PV；
• 已准备远程控制台或救援环境；
• 已知晓分区表刷新可能要求重启。

扩展分区通常不移动已有数据，但分区表操作本身属于高风险操作。若 lsblk 的分区大小已经变大，就不要重复执行分区扩展，而应进入 pvresize 检查。

第三层：分区变大但PV没有变

确认分区大小后，查看PV：

pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
pvdisplay /dev/vda3

如果 /dev/vda3 已经接近200G，但PV仍显示约80G，可以执行：

pvresize /dev/vda3
pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
vgs -o vg_name,vg_size,vg_free

pvresize 通常只更新LVM对现有块设备容量的认识，不会修改文件系统内容。正常结果是 pv_size 增大，且VG出现相应的 vg_free。

如果提示没有可调整空间，可能存在以下情况：

1. 分区实际上没有变大，lsblk 显示的是另一块磁盘；
2. PV直接建立在整块磁盘上，而不是分区上；
3. /dev/vda3 是加密层或RAID成员，真正的PV路径并非它；
4. 分区表已改变，但内核尚未重新读取；
5. 使用了LVM thin pool、快照或其他特殊布局。

此时不要强行指定新的PV大小。先查看完整映射：

lsblk -f
pvs -a -o pv_name,vg_name,pv_size,pv_free,pv_used
lvs -a -o lv_path,lv_size,lv_attr,segtype,data_percent,metadata_percent

如果 pvs 显示PV直接是 /dev/vda，就不需要执行针对 /dev/vda3 的命令。若中间存在加密映射或RAID，需要按照该存储层的顺序扩展，不能将普通分区LVM流程直接套用。

第四层：VG有空闲空间但根LV没有变

当 vgs 显示有足够的 vg_free，说明分区和PV阶段基本已经完成。此时先确认根LV的准确路径：

findmnt -no SOURCE /
lvs -o lv_path,vg_name,lv_name,lv_size,lv_attr,segtype

例如根LV路径为 /dev/vg0/root，需要增加20GiB时，可以先用测试模式检查：

lvextend --test -L +20G /dev/vg0/root

确认目标路径和可用空间无误后再执行：

lvextend -L +20G /dev/vg0/root

如果希望把VG剩余空间全部给根LV，可以使用：

lvextend -l +100%FREE /dev/vg0/root

但这会消耗该VG中的全部空闲PE。若同一VG还要为数据库、日志或其他挂载点预留空间，不应直接使用 +100%FREE。扩容前后检查：

lvs -o lv_path,lv_size,lv_attr,segtype
vgs -o vg_name,vg_size,vg_free

如果 lvextend 报告空间不足，不能只看磁盘总容量。需要确认：

• vgs 中是否真的有足够 vg_free；
• 根LV是否属于目标VG；
• 是否存在快照占用空间；
• lvs 中是否显示 t 开头的thin LV；
• thin pool 的 data_percent 和 metadata_percent 是否接近满载。

对于thin provisioning，虚拟磁盘容量、thin LV虚拟容量、thin pool实际容量是三个不同概念。普通LV扩容命令不一定能解决thin pool本身空间不足的问题，应先确认布局。

第五层：LV变大但文件系统仍未变

这是“LVM扩容后根分区未变大”最常见的原因之一。lvs 已显示根LV变大，但 df -h / 仍是原容量，说明文件系统没有使用LV新增的块。

先确认文件系统类型：

findmnt -no SOURCE,FSTYPE,TARGET /

ext4文件系统

如果结果为 ext4，根目录通常可以在线扩容：

resize2fs /dev/vg0/root
df -hT /
df -ih /

把 /dev/vg0/root 替换为 findmnt 返回的真实LV路径。resize2fs 不应对XFS设备使用。

XFS文件系统

如果结果为 xfs，应针对已挂载的根目录执行：

xfs_growfs /
df -hT /
df -ih /

XFS扩容命令的目标是挂载点 /，不是把块设备路径直接传给 xfs_growfs。

其他文件系统

如果显示为Btrfs、F2FS或其他文件系统，不要照搬ext4或XFS命令。先确认该文件系统的在线扩容方式和当前挂载状态。对于根文件系统尤其不要尝试格式化、强制修复或不明参数的缩容操作。

也可以使用LVM的自动扩容选项：

lvextend -r -L +20G /dev/vg0/root

-r 会尝试同时扩展文件系统，但如果文件系统类型、挂载状态或系统工具不匹配，可能出现“LV已经变大、文件系统仍未变大”的半完成状态。为了便于定位问题，生产环境更适合把LV扩展和文件系统扩展分开执行，并在每一步检查结果。

根目录空间没有变小，但业务仍提示磁盘异常

容量扩展成功，不代表所有磁盘异常都会自动消失。根目录使用率仍然很高时，应区分容量、inode、I/O延迟和日志增长。

检查容量使用率

df -hT /
du -xhd1 / 2>/dev/null | sort -h
du -xhd1 /var 2>/dev/null | sort -h

df 统计的是文件系统已分配块，du 统计的是目录树中可见文件，两者不一致时可以进一步检查被进程打开但已经删除的文件：

lsof +L1

常见表现是：

• df -h / 显示已使用空间很高；
• du 汇总出来的目录大小明显偏小；
• lsof +L1 显示某个进程仍持有 (deleted) 文件。

此时不要直接删除或终止进程。应先确认文件属于哪个服务，再按照服务的重载或重启流程释放文件句柄，并评估对业务连接的影响。

ext4可能预留一部分空间给系统和特权进程，因此 df 中的可用空间不一定等于普通用户能够立即使用的空间。不要把“总容量没有完全显示”误判成LVM扩容失败。

检查inode是否耗尽

大量小文件会先耗尽inode，即使磁盘仍有较多GB空间，也可能无法创建新文件：

df -ih /
df -ih /var

可以按下面的方式理解结果：

80%左右可以作为提前关注线，90%以上应安排处理，接近100%则可能影响日志写入、临时文件创建和服务启动。这些数值是运维参考，不是所有业务都适用的硬性标准。

检查I/O延迟和内核错误

磁盘“有空间”不代表I/O正常。安装了 sysstat 时，可以使用：

iostat -xz 1 5

重点观察：

• await：读写请求从提交到完成的平均等待时间，单位通常是毫秒；
• r_await、w_await：分别表示读、写等待时间；
• aqu-sz：平均队列长度；
• %util：设备忙碌程度；
• r/s、w/s：每秒读写请求数。

单次采样不能说明问题，应结合业务空闲和高峰时段比较。对常见本地SSD场景，持续几十毫秒的等待时间通常值得调查；但云磁盘、突发型磁盘、备份任务和高并发写入都会改变正常范围，不能仅凭一个阈值判定磁盘故障。%util长时间接近100%通常说明设备或队列处于高负载，但在并行设备上也不能单独作为故障结论。

同时查看CPU等待和内核日志：

vmstat 1 5
journalctl -k -p warning..alert --since "2 hours ago"

可以重点搜索以下类型的记录：

• I/O error
• blk_update_request
• reset
• timeout
• EXT4-fs error
• XFS
• Buffer I/O error

如果扩容后出现I/O错误、文件系统错误或设备重置，不要继续进行缩容、格式化或反复刷新分区表。先保存日志，并通过维护控制台、磁盘快照或备份确认数据状态。

检查日志是否持续增长

系统日志和应用日志可能快速消耗新增空间：

journalctl --disk-usage
du -xhd1 /var/log 2>/dev/null | sort -h
find /var/log -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -n

如果发现某个日志持续增长，先定位根因，例如服务重复报错、磁盘挂载失败、权限错误或上游连接异常。不要为了释放空间直接清空正在写入的日志文件。

journalctl --vacuum-time、删除旧日志或手工截断日志都可能影响审计和故障追踪。执行清理前应确认保留周期、完成必要备份，并确保不会删除当前排障所需的记录。更稳妥的处理方式是检查日志轮转策略和服务错误来源，让日志增长恢复到可控范围。

文件系统检查不能在已挂载根分区上强行执行

扩容成功但出现文件系统错误时，需要将“容量问题”和“文件系统一致性问题”分开处理。以下检查命令只用于非破坏性检查，但根分区通常需要进入救援系统、维护模式或从其他系统启动后执行。

ext4可以在未挂载状态下检查：

e2fsck -fn /dev/vg0/root

其中：

• -f 表示即使看起来干净也执行检查；
• -n 表示不写入修复结果。

XFS可以在未挂载状态下进行只读式检查：

xfs_repair -n /dev/vg0/root

不要对已挂载的根分区直接执行普通 fsck、e2fsck -y 或 xfs_repair。自动修复命令可能修改元数据，影响范围不限于本次扩容。需要修复时，应先完成备份，准备控制台或救援环境，并根据检查结果决定是否执行正式修复。

回滚应按扩容阶段处理

扩容操作并不是所有阶段都能简单反向执行。尤其是文件系统已经变大后，不能把LV直接缩回原大小。

还没有修改数据时

如果只是完成了磁盘侧扩容、重新扫描或分区刷新，还没有执行 pvresize、lvextend 和文件系统扩展，通常不需要回滚。保留新增容量不会改变原文件系统内容；如果必须恢复原磁盘大小，应通过平台快照或备份恢复，而不是在线删除分区。

只扩展了分区

分区变大但PV还没有使用新增区域时，最安全的做法通常是保留更大的分区。若确实要缩回，必须同时满足以下条件：

• 已准确记录原分区起始和结束位置；
• PV没有在新增尾部写入任何PE；
• 已完成可恢复备份；
• 具备维护环境和控制台；
• 由熟悉分区表和LVM的人员执行。

不要采用“删除分区后重新创建”的方式尝试回滚。起始扇区错误会使原有PV无法识别，甚至造成数据不可恢复。

只执行了PV扩展

如果PV已经变大，但没有在新增区域创建LV或分配PE，理论上可以在确认没有已分配PE位于旧边界之后，使用旧容量执行 pvresize --setphysicalvolumesize。例如：

pvs -o pv_name,pv_size,pv_used,pv_free
pvdisplay --maps /dev/vda3

只有在明确知道旧PV容量，并确认所有已分配PE都位于旧范围内时，才考虑：

pvresize --setphysicalvolumesize OLD_SIZE /dev/vda3

OLD_SIZE 必须替换成准确的原值，不能凭记忆填写。若LVM提示有分配的PE超出目标边界，应立即停止，不要加参数强制执行。

LV已扩展，但文件系统还没有扩展

如果只是执行了 lvextend，而 resize2fs 或 xfs_growfs 尚未执行，根文件系统仍按旧LV大小工作。此时可以在备份和维护条件具备的情况下，依据扩容前准确记录的LV大小进行评估。

建议先使用测试模式：

lvreduce --test -L OLD_SIZE /dev/vg0/root

如果路径、旧容量和文件系统状态都确认无误，再由有经验的运维人员在维护窗口执行实际缩回。不能把当前输出中的任意容量当作 OLD_SIZE，也不能在没有扩容前记录的情况下猜测。

文件系统已经扩展

一旦ext4或XFS文件系统已经使用新增空间，不能直接执行：

lvreduce -L OLD_SIZE /dev/vg0/root

这可能截断文件系统，造成严重数据损坏。

ext4缩容需要在未挂载状态下先缩文件系统，再缩LV，并且要经过完整备份和容量校验。XFS不支持常规在线缩容，通常需要新建更小的文件系统，再通过备份恢复或文件级迁移完成回退。若之前创建了可用的LVM或平台级快照，也只能在确认快照完整、空间未耗尽且了解恢复影响的前提下进行回滚。

因此，扩容前的正确做法不是依赖事后缩回，而是：

vgcfgbackup

保存LVM元数据，并对重要数据完成可恢复备份或平台快照。vgcfgbackup 只保存LVM配置，不等于业务数据备份，也不能替代文件系统和数据库备份。

扩容完成后的验收标准

容量链路验收

扩容后重新执行：

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
vgs -o vg_name,vg_size,vg_free
lvs -o lv_path,lv_size,lv_attr,segtype,data_percent,metadata_percent
findmnt -no SOURCE,FSTYPE,TARGET /
df -hT /

正常情况下：

1. 磁盘容量与平台侧目标容量一致；
2. 承载PV的分区大小已经覆盖新增区域；
3. PV容量接近对应分区容量；
4. VG空闲空间符合预期，或已按计划分配给根LV；
5. 根LV容量已经增加；
6. df -hT / 显示文件系统可用总容量增加。

df、LV和PV之间存在少量差异是正常的，原因可能包括文件系统元数据、ext4预留块、对齐和LVM元数据占用。验收重点是容量链路是否连续，而不是要求所有数字完全相等。

inode、I/O和文件系统验收

df -ih /
iostat -xz 1 5
journalctl -k -p warning..alert --since "30 minutes ago"
journalctl --disk-usage

可以按下面的项目留存判断：

inode使用率达到80%可以作为预警，达到90%应安排处理；I/O延迟则应优先与服务器自身的历史基线比较，不能把单一毫秒数当成所有环境的统一故障线。

留证和持续观察

建议把扩容前、扩容后立即检查、业务运行一段时间后的结果分别保存。可以使用以下命令生成复测记录：

OUT="/root/lvm-check/after-$(date +%F-%H%M%S)"
mkdir -p "$OUT"

{
    date -Is
    echo '--- block devices ---'
    lsblk -o NAME,TYPE,SIZE,START,FSTYPE,MOUNTPOINTS
    echo '--- LVM ---'
    pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
    vgs -o vg_name,vg_size,vg_free
    lvs -a -o lv_path,vg_name,lv_name,lv_size,lv_attr,segtype,data_percent,metadata_percent
    echo '--- root filesystem ---'
    findmnt -no SOURCE,FSTYPE,OPTIONS,TARGET /
    df -hT /
    df -ih /
    echo '--- journal usage ---'
    journalctl --disk-usage
    echo '--- kernel warnings ---'
    journalctl -k -p warning..alert --since "30 minutes ago"
} 2>&1 | tee "$OUT/summary.txt"

扩容后的第一次复测确认容量链路，第二次复测应在业务运行一段时间后进行，重点观察根目录可用空间、inode增长、日志增长速度和I/O等待。如果容量确实增加，但很快再次被日志、缓存或小文件耗尽，问题就不再是LVM扩容，而是空间增长来源需要继续治理。

对远程香港服务器进行这类操作时，Linux命令和LVM判断逻辑与其他机房环境没有区别，但应特别注意SSH断连、重启后设备名变化和缺少本地操作入口等风险。保留控制台、备份和分层证据后，再进行下一步操作，通常比反复执行扩容命令更容易安全完成根分区扩展。