昨天接了非常简单但又有坑的踩坑车私活。一个粉丝用户找到我，经验决磁让我帮处理一个磁盘扩容的户解问题，因为这种问题比较简单，盘扩我就爽快答应了。容问

他们操作系统是题差CentOS7，/data盘目前已经100%了，点翻上面跑是踩坑车MySQL和PG数据库都挂了，业务也连不上。经验决磁但他们这块盘有2.5T扩容，户解只用了1T，盘扩运维刚好走了，容问需要协助扩容。题差

因为我是点翻远程协助处理的，首先让他先在云平台给这台服务器打个快照，踩坑车备份一下重要的数据，这很重要。

作为运维工程师，我早已司空见惯。登录服务器，确认磁盘情况：

复制df -h /data1.

输出显示：

复制Filesystem Size Used Avail Use% Mounted on /dev/vdb1 985G 935G 0 100% /data1.2.

确实已经100%了。这是一块2.5TB的云磁盘，按理说应该很充裕才对。

1. 第一次扩容踩坑

我熟练地执行了标准的扩容命令：

复制growpart /dev/vdb 11.

然而，WordPress模板等待我的不是成功的提示，而是一串报错信息：

正常执行这条命令后，/dev/vdb的所有空间扩容到/dev/vdb1。但是出现了报错，好像是分区表冲突了，还提示有数据丢失风险，突然认真了起来。

2. 深入排查

接下来，我开始仔细排查。首先查看磁盘的详细信息：

复制fdisk -l /dev/vdb1.

输出结果令人惊讶：

再用parted确认：

复制parted /dev/vdb print1.

问题有三个方面：

磁盘实际大小2.5T，但只划分了1T的分区分区表是GPT类型（正确，因为大于2TB）文件系统只格式化了985G，没有占满整个1T分区

但是为什么我执行growpart /dev/vdb 1会失败呢？我问那个人好像也不太清楚，我总结了可能的原因：

可能之前有人尝试在大于2TB的磁盘上使用MBR分区表后来发现无法使用全部空间，又创建了GPT分区表但没有正确清理旧的MBR信息，导致两者并存，变成了一个"混合式"的分区表，既有GPT信息，免费源码下载又有非保护性的MBR信息。3. 解决方案

由于是ext4文件系统，他不支持在线扩容空间，既然growpart已经不可行，我就换成parted来处理，但需要卸载分区才能扩容，经用户同意后开始恢复操作。

(1) 卸载分区

首先需要卸载分区：

复制umount /data1.

但系统提示：

复制umount: /data: target is busy.1.

这意味着有进程正在使用这个目录。使用以下命令找出罪魁祸首：

复制lsof /data1.

看到很多MySQL文件还占用这个目录，应该是异常中断，有些进程没有完全退出，我就用ps -ef |grep mysql命令找出MySQL进程，然后用kill -9 PID杀掉后，成功卸载/data分区

(2) 安全检查与扩容

卸载成功后，按顺序执行：

复制# 文件系统检查（强烈推荐！） e2fsck -f /dev/vdb1 # 扩容分区至磁盘末尾 parted /dev/vdb resizepart 1 100% # 刷新系统分区表信息 partprobe /dev/vdb # 4. 扩容文件系统 resize2fs /dev/vdb1 # 5. 重新挂载（这步如果系统启动了自动挂载，可不执行就自动挂载 mount /dev/vdb1 /data1.2.3.4.5.6.7.8.9.10.11.12.13.14.

(3) 验证成果

最后检查扩容结果：

复制df -h /data1. 复制lsblk /dev/vdb1.

整个扩容过程就完成了。

4. 技术要点总结和建议MBR vs GPT：大于2TB的磁盘必须使用GPT分区表，分区前做好划分分区 vs 文件系统：分区大小和文件系统大小是两回事，我平时不喜欢将一块数据盘再进行分区，直接格式化来用，容易扩容操作前先诊断：知其然更要知其所以然，我开始就犯了个小错误，上来就扩容，没有弄清楚情况。读懂错误信息：错误信息往往包含了解决方案的线索备份是最后的香港云服务器防线：我一上来就让用户打个快照和备份，必要时进行回滚。

最后想说的是：赚钱不易，操作需谨慎，别把自己搭进去了！

(责任编辑：IT科技类资讯)