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

注意事项（操作前必读）

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

---

正文

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

1. 查看当前状态

df -h / /home
vgs

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

2. 检查占用 /home 的进程

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. 终止占用进程

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

4. 卸载 /home

umount /home

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

umount -l /home

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

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

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

6. 缩小逻辑卷

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

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（不可逆）

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

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

8. 挂载 /home

mount /home

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

---

二、扩容根分区

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

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

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

10. 在线扩容 XFS 文件系统

xfs_growfs /

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

11. 验证结果

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。

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 恢复：

systemctl start mongod.service

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

预防措施

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

---

End

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

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

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