存储扩容需打通硬件、驱动、逻辑抽象到文件系统全链路，关键在“扩得稳、用得上”：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”报错。
