阿里云ebs在线扩容本质是“分区扩展+文件系统扩展”两步：先在控制台完成云盘扩容并确认size更新，再在系统内用growpart扩分区（如有分区）、按文件系统类型执行resize2fs（ext4）或xfs_growfs（xfs）扩文件系统，最后用df -th验证挂载点容量。
在线扩容新增云硬盘，本质是“分区扩展 + 文件系统扩展”两步，但必须分清：云盘本身是否已扩容、是否已有分区、文件系统类型是什么。控制台扩容只是第一步，不执行后续操作，df -h 看到的容量永远不变。
确认云盘是否已完成控制台扩容
这是最容易跳过的前提。很多用户以为在 ECS 控制台点了“扩容”就完了，其实那只是让底层块设备变大，操作系统还“看不见”新空间。
- 登录 ECS 控制台 → 块存储 → 云盘，确认目标盘“容量”已更新（如从 100 GiB 变为 200 GiB）且状态为“使用中”
- 在服务器内执行
lsblk，对比输出中的 SIZE 列和分区大小（如/dev/vdb是 200G，但/dev/vdb1还是 100G），差值就是待分配空间 - 若
lsblk显示整块盘（如/dev/vdb）大小未变，说明控制台扩容没生效或未完成支付/确认，此时所有后续命令都会失败
判断是否需要扩容分区（growpart 用不用）
关键看云盘有没有分区表。裸设备（无分区）可直接扩文件系统；有分区（如 /dev/vdb1）则必须先扩分区，否则 resize2fs 或 xfs_growfs 会报 “The filesystem is already xxx bytes” —— 它不是不想扩，是分区没给它空间。
- 执行
sudo fdisk -l /dev/vdb（把/dev/vdb换成你的盘） - 如果输出里有
/dev/vdb1这类设备，且 Disklabel type 是gpt或dos，说明有分区 → 必须运行growpart /dev/vdb 1 - 如果只有
Disk /dev/vdb行，下面没有/dev/vdb1，说明是裸设备 → 跳过growpart，直接扩文件系统 -
growpart命令格式严格：growpart /dev/vdb 1（空格分隔，不是/dev/vdb1）；若提示 “failed”，先试partprobe /dev/vdb刷新内核分区表
按文件系统类型选择扩容命令
ext4 和 XFS 的处理逻辑完全不同，混用必报错。别凭印象记，每次操作前用 df -T 或 blkid 实锤。
- ext4/ext3/ext2：必须用
resize2fs，且支持在线扩容（无需umount）
→ 扩分区后执行：resize2fs /dev/vdb1（对分区设备） - XFS：必须用
xfs_growfs，且**只认挂载点，不认设备名**
→ 若/dev/vdb1挂载在/data，执行：xfs_growfs /data（不是/dev/vdb1） - 若误对 XFS 执行
resize2fs，会报 “Filesystem does not have resize2fs support”；反之对 ext4 执行xfs_growfs会报 “XFS signature detected on …”
验证与常见失败点
最后一步不是收工，而是交叉验证。很多人看到 resize2fs 输出 “done” 就以为完事，结果 df -h 容量没变，问题往往出在路径或层级上。
- 执行
df -Th，确认目标挂载点（如/data）的 Size 是否接近云盘总容量（允许差 1–3 GiB，因文件系统元数据占用） - 若仍显示旧容量，检查是否漏了
growpart（尤其 GPT 分区，fdisk -l可能不显示分区，但lsblk会显示/dev/vdb1） - LVM 场景下，
resize2fs或xfs_growfs的对象是逻辑卷（如/dev/mapper/vg00-lv_data），不是物理盘；此时growpart完全不需要 - 内核低于 3.6.0 时，
growpart可能失效，需改用parted手动resizepart，且必须确保起始扇区不变
真正卡住的点，往往不在命令本身，而在没搞清“当前设备到底属于哪种结构”——是裸盘？MBR 分区？GPT 分区？LVM 逻辑卷？还是 XFS 挂载点？每种结构对应一套操作链，混搭就失败。动手前花 2 分钟跑一遍 lsblk && df -T && sudo fdisk -l /dev/vdX，比重试三遍强得多。
