CentOS 8 LVM 在线扩容根分区：从 home 安全割让空间（XFS 文件系统）

CentOS 8 LVM 在线扩容根分区：从 /home 割让空间（XFS 文件系统）

一级目录
- 二级目录
- - 三级目录
- 背景
- 环境信息
- 注意事项（操作前必读）
- 正文
- - [一、缩小 /home 逻辑卷，释放空间到卷组](#一、缩小 /home 逻辑卷，释放空间到卷组)
  - - [1. 查看当前状态](#1. 查看当前状态)
    - [2. 检查占用 /home 的进程](#2. 检查占用 /home 的进程)
    - [3. 终止占用进程](#3. 终止占用进程)
    - [4. 卸载 /home](#4. 卸载 /home)
    - [5. 检查文件系统（可选）](#5. 检查文件系统（可选）)
    - [6. 缩小逻辑卷](#6. 缩小逻辑卷)
    - [7. 重新格式化 /home（不可逆）](#7. 重新格式化 /home（不可逆）)
    - [8. 挂载 /home](#8. 挂载 /home)
  - 二、扩容根分区
  - - [9. 将所有空闲空间分配给根逻辑卷](#9. 将所有空闲空间分配给根逻辑卷)
    - [10. 在线扩容 XFS 文件系统](#10. 在线扩容 XFS 文件系统)
    - [11. 验证结果](#11. 验证结果)
- [请添加图片描述 ! $请添加图片描述$ (https://i-blog.csdnimg.cn/direct/f273b688e56a4f01b5d8113a20f8197d.png) ! $请添加图片描述$ (https://i-blog.csdnimg.cn/direct/4fe4dd28a988404eabd479616a3a228d.png) ! $请添加图片描述$ (https://i-blog.csdnimg.cn/direct/8a58bc9ac53e448d9eb5b31e12d9ebdb.png)](#请添加图片描述 )
- - [三、MongoDB 异常退出故障分析](#三、MongoDB 异常退出故障分析)
- End

)

一级目录

二级目录

三级目录

背景

CentOS 8 服务器在安装时采用了默认分区方案，导致根分区 / 仅分配 70G，而 /home 独占了 390G 且实际使用不到 5G。随着 Docker、数据库等服务持续运行，根分区空间逐渐耗尽，需要在不重启、不停 Docker、不改变路径、不添加硬盘的前提下扩容。

问题在于 /home 使用 XFS 文件系统------XFS 不支持在线缩小（没有 xfs_shrink 命令），只能通过卸载 → 缩小 LV → 重新格式化 → 挂载的方式释放空间，再将空闲空间追加到根分区。

环境信息

项目	值
操作系统	CentOS 8
分区方案	LVM
卷组名称	`cl_miwifi-ra80-srv`
根逻辑卷	`cl_miwifi-ra80-srv-root`（70G，XFS）
home 逻辑卷	`cl_miwifi-ra80-srv-home`（390G，已用 4.8G，XFS）
卷组空闲	0

注意事项（操作前必读）

/home 数据会被彻底清空 。XFS 不支持在线缩小，流程是 lvreduce → mkfs.xfs → mount，中间 mkfs 会抹掉 /home 上的所有数据。操作前必须备份 /home。
检查 Docker volume 和数据库数据目录 。如果任何容器的 volume 或 bind mount 指向 /home 下的路径，mkfs 之后这些数据将不可恢复。用 docker inspect 逐一确认，必要时迁移到 /var 或根分区其他位置。
xfs_growfs / 可能间接导致运行中的服务异常 。虽然 xfs_growfs 号称在线操作，但在更新文件系统元数据时会产生短暂的 I/O 抖动。本次操作中 MongoDB（数据目录在 /var/lib/mongo，与 /home 无关）因 I/O 阻塞导致 WiredTiger 引擎异常退出（exit code 14），详见下文故障分析。
生产环境禁止使用
确认文件系统类型 。df -T 检查，ext4 的缩小流程不同（resize2fs 可在线缩小），本文步骤仅适用于 XFS。

正文

一、缩小 /home 逻辑卷，释放空间到卷组

1. 查看当前状态

bash 复制代码

df -h / /home
vgs

确认根分区已满、home 几乎空闲、卷组无剩余空间。

2. 检查占用 /home 的进程

bash 复制代码

fuser -vm /home
lsof /home

输出示例（普通用户 paul 的桌面进程，不影响业务）：

复制代码

                     USER        PID ACCESS COMMAND
/home:               root     kernel mount /home
                     paul       2889 ..c.. dbus-daemon
                     paul       2989 ..c.. gvfsd
...（省略）

3. 终止占用进程

bash 复制代码

pkill -u paul          # 替换为实际用户名
fuser -vm /home        # 确认仅剩 root 的 kernel mount

4. 卸载 /home

bash 复制代码

umount /home

若报 target is busy，使用 lazy 卸载：

bash 复制代码

umount -l /home

补充：若 lazy 卸载仍失败，用 fuser -vm /home 找出残留 PID，kill -9 <PID> 后重试 umount。

5. 检查文件系统（可选）

bash 复制代码

xfs_repair /dev/mapper/cl_miwifi--ra80--srv-home

6. 缩小逻辑卷

将 /home 从 390G 缩小到 50G（实际仅用 4.8G，50G 绰绰有余）：

bash 复制代码

lvreduce -L 50G /dev/mapper/cl_miwifi--ra80--srv-home -f

输出：

复制代码

WARNING: Reducing active logical volume to 50.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Size changed from 389.66 GiB to 50.00 GiB.

技巧：若要精确控制 /home 最终大小（如 85G），先缩到较小值（如 50G），再用 lvextend -L 85G /dev/mapper/.../home && xfs_growfs /dev/mapper/.../home 扩回。注意 lvreduce 只能缩小，无法从 50G "缩小" 到 85G。

7. 重新格式化 /home（不可逆）

bash 复制代码

mkfs.xfs /dev/mapper/cl_miwifi--ra80--srv-home -f

此步不可跳过。XFS 不支持缩小文件系统，缩 LV 后 XFS 元数据仍认为磁盘大小为 390G，直接挂载会导致文件系统错误。

8. 挂载 /home

bash 复制代码

mount /home

此时卷组已释放约 340G 空闲空间，可通过 vgs 确认。

二、扩容根分区

9. 将所有空闲空间分配给根逻辑卷

bash 复制代码

lvextend -l +100%FREE /dev/mapper/cl_miwifi--ra80--srv-root

-l +100%FREE 将卷组中所有剩余空间追加给根 LV。

10. 在线扩容 XFS 文件系统

bash 复制代码

xfs_growfs /

此命令无需卸载根分区，实时生效。

11. 验证结果

bash 复制代码

df -h / /home
vgs

结果：

复制代码

Filesystem                                Size  Used Avail Use% Mounted on
/dev/mapper/cl_miwifi--ra80--srv-root     410G   70G  340G  17% /
/dev/mapper/cl_miwifi--ra80--srv-home      50G  4.8G   45G  10% /home

根分区从 70G 扩容至约 410G，净增约 340G。/home 保留 50G，卷组剩余空间归零。

三、MongoDB 异常退出故障分析

扩容完成后，Docker 和 MySQL 均正常运行，但 MongoDB 服务状态为 failed。

bash 复制代码

systemctl status mongod.service

复制代码

● mongod.service - MongoDB Database Server
   Active: failed (Result: exit-code)
 Main PID: 1968 (code=exited, status=14)

原因分析

MongoDB 为原生 systemd 服务，数据目录 /var/lib/mongo 位于根分区，与 /home 操作无直接关联。问题出在步骤 10 的 xfs_growfs /：

xfs_growfs 虽支持在线扩容，但在更新 XFS 超级块和 AG（Allocation Group）元数据结构时，会产生短暂的 I/O 阻塞（通常几十到几百毫秒）。MongoDB 的 WiredTiger 存储引擎对 I/O 延迟极其敏感------其 checkpoint 和 journal 写入依赖文件系统在毫秒级内完成 I/O 操作。一旦 xfs_growfs 造成的 I/O 抖动超出 WiredTiger 的容忍阈值，引擎即判定为存储层致命错误并主动退出（exit code 14，表示非正常关闭）。

MongoDB 退出后，systemd 默认 Restart=on-failure 会尝试重启，但 exit code 14 要求 MongoDB 先通过 journal 恢复数据。若恢复过程中再次失败，systemd 在数次重试后放弃，服务最终进入 failed 状态。

修复方法

手动启动即可，MongoDB 自动从 WiredTiger journal 恢复：

bash 复制代码

systemctl start mongod.service

恢复成功后服务正常运行，数据完整。exit code 14 不代表数据损坏，仅表示上次关闭不干净、需要恢复。

预防措施

操作方法 ：在 xfs_growfs / 之前先 systemctl stop mongod，完成后再 systemctl start mongod。
同样适用于其他 I/O 敏感服务：Elasticsearch、PostgreSQL、Redis 等。短暂的主动停服远比事后被动抢救可控。
如不能停服，至少在低峰期执行，确保数据库没有大事务或密集写入。

End

本次操作在不重启服务器、不停 Docker、不改变数据路径、不添加物理磁盘的前提下，将根分区从 70G 扩容至 410G。核心流程为：

fuser + pkill 清理 /home 占用进程
umount /home → lvreduce → mkfs.xfs → mount /home
lvextend -l +100%FREE + xfs_growfs / 在线扩容根分区

但是MongoDB 还是因 xfs_growfs 的 I/O 抖动异常退出，本方案适用于 CentOS 7/8、RHEL 等使用 LVM + XFS 的 Linux 发行版，正式项目不要用！