在之前的文章介绍过在 AWS 上调整 EBS 卷然后扩容文件系统AWS调整EC2的EBS卷大小及二次踩坑，没过多久又再次踩坑。直接说出原因是和 AWS 没啥关系，原因竟然是使用 MBR 分区导致的。下面来描述下踩坑经历。
问题回溯
在 CentOS 7 mysql 服务器上，对挂载在/mysqlData02 的 /dev/nvme3n1 EBS 卷进行扩容2T-> 3T，EBS 卷已经调整到 3T 系统上也可以看到
/dev/nvme3n1 块设备大小变成 3T
这时候到了使用 growpart 命令并指定要扩展的分区，但是 NOCHANGE: partition 1 is size 4294965248. it cannot be grown 出现报错。
查看 AWS 官档故障排除技巧也没找到有用信息
回到报错NOCHANGE: partition 1 is size 4294965248. it cannot be grown，报错说分区 1 大小已经到 4T，但是实际我才调整到 3T。所以这里让人很迷。fdisk 查看 nvme3n1 磁盘分区 1 的确是到了 4T。
但是使用 parted 查看结果就不一样
问题分析
fdisk 和 parted 命令执行返回为什么不一样呢？这里简单介绍下他们两者区别， fdisk 是一个较老的磁盘分区表创建和管理工具，以前支持 MBR 分区但是不支持 GPT 分区，较新的版本是支持 GPT 分区 ；parted 是一种更现代的工具，旨在处理大型磁盘，并支持多种分区表格式比如 MBR 和 GPT。从上面 fdisk 和 parted 执行结果看到（parted: Partition Table:msdos 就是 MBR 分区, fdisk: Disk label type:dos , MBR 也被称为 "DOS" 分区表），nvme3n1是使用 MBR 分区，而 MBR 分区最大支持 2T。这才导致无法将文件系统扩展到 2T 以上.....
最后
因为使用的是 MBR 分区导致无法扩容，同时也导致EBS 卷那 1 T 空间浪费了，解决方案只能重新购买一块新的 EBS 卷还有使用 GPT 分区，然后停止数据读写然后进行数据迁移。哎，这就非常非常的难受了。
