存储扩容需打通硬件、驱动、逻辑抽象到文件系统全链路，关键在“扩得稳、用得上”：LVM须逐级执行PV→VG→LV→文件系统扩展；云盘需控制台扩容后运行growpart与xfs_growfs/resize2fs；RAID5扩容依赖重建；分布式存储需兼顾节点扩展与数据均衡。

存储扩容不是“加块硬盘就完事”，而是一条从硬件、驱动、逻辑抽象到文件系统的完整链路。真正卡住扩容效果的，往往不是容量不够，而是某一层没打通——比如云盘在控制台扩完了，系统里却没识别新空间；LVM卷组加了新盘，逻辑卷没延伸，文件系统更没刷新；分布式存储节点加进去了，数据却压根没平衡过去。关键不在“能不能扩”，而在“扩得稳不稳、用得上不用得上”。

先确认扩容路径：按架构选对方法

不同底层架构，扩容逻辑完全不同：

• LVM环境：核心是“PV → VG → LV → 文件系统”四层逐级打通。漏掉任何一层（尤其是最后的 resize2fs 或 xfs_growfs），df 就看不到新增空间。
• 云硬盘（如阿里云EBS、腾讯云CBS）：必须分两步——先在控制台扩容云盘，再进系统执行分区扩展（growpart）和文件系统扩展。在线扩容支持免重启，但仅限于未使用MBR主引导记录的场景。
• RAID5：不能靠“换大盘”释放空间。原始阵列容量由最小成员盘决定，全换大容量盘后仍需重建阵列才能生效。
• 分布式存储（HDFS/vSAN/Ceph）：扩容主体是节点或磁盘组，但真实可用容量受副本策略、预留空间、数据倾斜三重折扣影响，必须重新测算，不能简单按物理容量线性推算。

动手前必做的三件事

别急着敲命令，这三步跳过，90%的扩容问题都出在这里：

• 查清当前结构：运行 lsblk -f 看设备树和挂载点，pvs/vgs/lvs（若用LVM），df -h 对比挂载点与底层设备容量是否一致。
• 确认文件系统类型：ext4 用 resize2fs，xfs 必须用 xfs_growfs（且只支持在线扩展，不支持缩容）；误用命令会导致操作失败甚至损坏元数据。
• 备份关键状态：记下扩容前的 pvdisplay、vgdisplay 输出，对重要数据盘创建快照。RAID 和分布式存储还要保存当前均衡状态（如 HDFS 的 hdfs dfsadmin -report）。

常见扩容场景实操要点

不是所有扩容都一样，重点看瓶颈在哪：

• 云服务器数据盘告警（无LVM）：先在控制台扩容云盘 → 进系统用 growpart /dev/vdb 1 扩展分区 → 再执行 xfs_growfs /data（xfs）或 resize2fs /dev/vdb1（ext4）。
• LVM根分区或业务卷不足：新加物理盘 → pvcreate /dev/sdc → vgextend vg_name /dev/sdc → lvextend -l +100%FREE /dev/vg_name/lv_root → 最后才是文件系统扩展。
• HDFS集群容量紧张：加DataNode只是第一步；上线后必须跑 hdfs balancer -threshold 5 均衡数据；同时检查机架感知配置是否正确，否则新节点可能长期空转。
• vSAN纵向加盘：不能只看“还能插几块”，要卡死在磁盘组限制（单主机≤5组，每组≤1缓存盘+7容量盘）；FTT=1时，加2TB盘仅增加约1TB可用空间，扩容前务必用 vSAN Sizer 重算。

扩容后必须验证的三个指标

做完不等于做对，这三个点不验，等于白干：

• 空间可见性：df -h 显示挂载点容量已更新，且与预期新增值基本一致（允许小数点后误差）。
• IO可用性：用 fio 或 dd 往新空间写入测试文件，确认无 I/O 错误；观察 iostat 中对应设备的 %util 和 await 是否正常。
• 服务连通性：如果是数据库或应用挂载点，重启服务或触发一次写操作（如 MySQL insert into test values(1)），确认无“no space left on device”报错。