扩容失败主因是层级衔接断裂：物理层、逻辑卷层、文件系统层、应用层任一环未同步，导致df -h容量未变、服务异常或数据不一致；须依链路逐层验证并执行对应操作（如rescan、pvresize、lvextend、resize2fs/xfs_growfs）。
存储扩容不是加块硬盘就完事，真正卡住人的，往往是扩容后空间没变、服务异常、数据不一致这些“看似成功实则失败”的状态。问题不出在硬件接入，而出在层级衔接——物理层、逻辑卷层、文件系统层、应用层，任一环断开，扩容就等于白做。
先确认是不是真扩容失败
别急着重操作，先验证现象是否属于典型扩容失效：
- Linux下
df -h显示容量未增长，但lsblk或cat /proc/mdstat已识别新磁盘或新成员 - Windows中磁盘管理看到卷已扩展，但资源管理器里C盘大小不变
- VSAN界面显示磁盘组容量增加，但vCenter里数据存储总容量无变化
- RAID5完成
mdadm --grow后，mdadm --detail显示新设备已加入，但cat /sys/block/md0/md/size数值未更新
四大高频卡点与对应解法
90%的扩容疑难都落在以下四个环节，每个环节都有明确验证和修复路径：
-
RAID阵列扩容完成，但文件系统没同步：这是最常见坑。Linux下必须手动执行
resize2fs /dev/md0（ext4）或xfs_growfs /mount/point（XFS）；Windows需右键卷→“扩展卷”，且目标空闲空间必须与该卷相邻 -
逻辑卷（LVM）中间层被跳过：加了物理卷（PV）却没扩展卷组（VG），或扩展了VG却没拉伸逻辑卷（LV）。依次运行：
pvcreate /dev/sdX→vgextend vg_name /dev/sdX→lvextend -l +100%FREE /dev/vg_name/lv_name→ 再文件系统扩容 -
云平台磁盘扩容后未通知操作系统：阿里云/AWS等扩容云盘后，Linux实例需执行
echo 1 > /sys/class/block/vda/device/rescan（vda为盘符），再partprobe或fdisk -l确认识别，最后才是文件系统扩容 - VSAN降低FTT应急后未恢复，导致后续扩容受限：FTT=0虽释放空间，但VSAN会拒绝向FTT降级后的磁盘组添加新磁盘。必须先在vCenter中将策略改回FTT=1（或原值），再执行扩容操作
排查时盯死三个关键指标
不靠猜，用命令定位瓶颈层：
-
物理层可见性：Linux用
lshw -class disk或smartctl -i /dev/sdX确认新盘被识别；ESXi用esxcli storage core list -
块设备层容量：Linux查
blockdev --getsize64 /dev/sdX看裸设备大小；Windows用diskpart → list disk → select disk X → detail disk -
文件系统层可用性：Linux用
tune2fs -l /dev/xxx | grep "Block count"对比扩容前后块总数；XFS用xfs_info /mount/point核对data字段中的bsize和blocks
预防比抢救更重要
每次扩容前花2分钟做三件事，能避开80%的返工：
- 记录当前
df -h、lsblk、cat /proc/partitions输出作为基线 - 确认文件系统类型（
df -T）并准备好对应扩容命令，避免ext4误用xfs命令 - 检查是否有挂载选项限制（如
noatime不影响，但ro只读会导致resize2fs失败）
