ECS数据盘扩容后如何分区？
在控制台扩容了ECS数据盘，但登录系统发现 df -h 显示的容量没有变化。这是因为扩容只是增大了云盘的物理容量，操作系统内的分区和文件系统还需要手动扩展。
不少团队在「ECS数据盘扩容后如何分区？」上走过弯路，根源通常是只优化了局部、却忽视了全局。ECS 实例选型与算力规划的价值恰恰体现在端到端的协同：从资源申请、网络互通，到弹性与容灾，每一步都需要统一的规范和口径。
Linux系统操作步骤
1. 查看磁盘状态：lsblk。你会看到磁盘总容量已经增大，但分区还是原来的大小。
2. 扩展分区：growpart /dev/vdb 1（将vdb的第1个分区扩展到最大）。如果提示"unexpected output"，先执行 LANG=en_US.UTF-8 growpart /dev/vdb 1。
3. 扩展文件系统：ext4用 resize2fs /dev/vdb1，xfs用 xfs_growfs /mnt/data（挂载点路径）。
4. 验证：df -h 确认容量已扩展。
没有分区的情况
如果数据盘没有分区（整盘使用，如 /dev/vdb 直接格式化为文件系统），不需要growpart步骤，直接 resize2fs /dev/vdb 即可。
注意事项
扩容前务必创建快照备份。数据盘扩容可以在线操作（不需要停机）。系统盘扩容后部分操作系统需要重启。如果growpart报错，可能是分区表格式问题（MBR不支持超过2TB，需要用GPT）。
扩容前的三个确认与常见报错
云盘扩容分两步：先在云平台侧扩大容量，再进操作系统里让分区与文件系统认识新空间。只做第一步，系统里看到的仍是旧容量。
- 动手前先快照：分区与文件系统操作不可逆，扩容前给云盘打快照，出问题可直接回退。
- 确认分区表与文件系统：MBR 与 GPT 的处理方式不同；ext4 用 resize2fs 扩展，xfs 用 xfs_growfs，两者不能混用。若数据盘当初未分区、直接格式化了整块盘，则只需扩展文件系统。
- 扩展分区：常用 growpart 扩分区号，再执行 partprobe 让内核重读分区表；工具缺失时先安装对应的云工具包。
常见报错对照：提示命令不存在多是工具没装；提示分区无变化通常是已经最大或分区表未重读；xfs 只能扩不能缩。另外要记住云盘扩容本身不支持缩容，容量规划要先算清楚，避免为了「先扩了再说」留下无法回退的成本。
把ECS 实例选型与算力规划放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估ECS 实例选型与算力规划时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，ECS 实例选型与算力规划才算真正「落地」，而不是停留在方案文档里。