XFS 数据盘无损扩容到 3TB：MBR 转 GPT 实战

最近处理了一台生产服务器的数据盘扩容。业务文件都放在 /defaultUploadFolder，原来只有 800G，使用率已经到了 98%。云平台侧已经把磁盘扩到了接近 3TB，但 Linux 里的分区和 XFS 文件系统还没有跟着扩。

这次比较麻烦的地方不在 XFS，而在分区表：这块盘还是老的 MBR/DOS 分区表，直接 growpart 最多只能用到 2TB。最后的处理路线是： 云盘扩容到 3TB → MBR 转 GPT → 扩大分区 → 扩大 XFS

整个过程没有迁移 800G 文件，也没有重新格式化。

---

一、 背景与问题定位

1. 确认磁盘与文件系统现状

扩文件系统之前一定先确认类型，不要凭经验猜。 先看块设备和磁盘空间：

再确认 UUID 和分区类型：

此时现状很明确：XFS 文件系统，当前 800G，仅剩 16G，急需扩容。

2. 遭遇 MBR 的 2TB 限制

原本打算直接扩容，先用 growpart 模拟（不真正修改）：

结果直接给出了警告：

WARNING: MBR/dos partitioned disk is larger than 2TB. Additional space will go unused.

label: dos

这说明 /dev/vdb 还是 MBR 分区表。在 512 字节扇区环境下，MBR 能管理的最大空间大约就是 2 TiB。即使强制执行 growpart，剩下接近 1TB 还是用不了。

因此，必须先将 MBR 转换为 GPT，才能一次性无损扩容到 3TB。 (注意：千万不要使用 parted /dev/vdb mklabel gpt，这是重新创建分区表，会清空数据！)

---

二、 扩容前置准备（关键）

1. 备份分区信息

这一步绝对不能省，且备份文件要放在系统盘 /root，不要放到正在操作的目录下。

关键点： 记录下分区1的起始扇区（如 start=2048），后面转换时必须保持一致。建议操作前在云平台打好磁盘快照。

2. 使用 gdisk 进行无损演练

安装 gdisk 并进行不写入磁盘的测试：

依次输入 p (查看准备转换的结构)、v (校验是否存在重叠冲突)、q (退出不保存)。 确认显示的 Start (sector) 依然是 2048，且校验结果为 No problems found. 即可。

---

三、 核心实战：转格式与扩容

步骤 1：停机卸载并正式转 GPT

先停止正在向数据盘写数据的服务（如 Java 进程、上传服务）。

再次进入 gdisk 正式转换：

依次输入 p、v，最后输入 w（写入）并输入 Y 确认。这一步只是修改分区表元数据，速度极快。

步骤 2：转换后验证

刷新设备并检查 GPT 是否生效：

重点提醒： MBR 转 GPT 后，分区的 PARTUUID 会变，但文件系统的 UUID 通常不变。建议检查 /etc/fstab，确保使用 UUID=xxx 挂载，而不是 PARTUUID，以免重启后挂载失败。

强烈建议在此步先挂载验证数据：

只要原来的 800G 文件能正常读取，说明转换成功，可以放心往下走。

步骤 3：扩大分区 (growpart)

确认没问题后，执行分区扩容：

此时 lsblk 会显示 vdb1 变成了 2.9T，但 df -h 依然是 800G，这是因为文件系统还没扩。

步骤 4：在线扩展 XFS 文件系统

XFS 支持在线扩容，直接对挂载点执行（注意不是对设备名执行）：

最后验证容量：

至此，无损扩容圆满完成。

---

四、 常见问题与避坑指南

1. 不要无脑执行 growpart 看到云盘变 3TB 后，养成先执行 growpart -N /dev/vdb 1 模拟的习惯。成本极低，但能提前发现 MBR 的 2TB 限制。
2. 警惕致命命令

• 严禁使用 parted mklabel gpt（会清空分区表）。
• 严禁使用 mkfs.xfs（这是格式化命令，会清空数据）。

3. 容量显示差异 扩容后 lsblk 显示 2.9T，而 df 显示 3.0T。这是因为各工具在 1000 与 1024 进制换算及四舍五入上存在差异，属于正常现象。
4. 操作耗时评估 核心命令执行只需十几分钟，主要时间花在停业务、做快照、备份及验证数据上。建议申请 30～60 分钟的维护窗口。

---

五、 完整命令流汇总 (Cheat Sheet)

为方便日后复用，可参考以下精简流程：

对这种核心数据盘操作，核心逻辑是步步为营：先验证 GPT 转换，再扩分区，最后扩文件系统。每一步确认无误后再继续，风险就能降到最低。