扩容后df -h未更新是因内核未重读分区表：裸设备需partprobe或rescan，有分区须先fdisk调整再partprobe，lvm/luks/raid等中间层也需对应扩容。
扩容后 df -h 不显示新容量，说明内核没重读分区表
扩容云盘后，df -h 仍显示旧大小，不是文件系统没扩容，而是内核还在用老的分区信息。裸设备（如 /dev/vdb）扩容后需通知内核刷新；有分区（如 /dev/vdb1）则必须先调整分区大小，再让内核识别新布局。
- 对未分区磁盘（
/dev/vdb），直接运行partprobe /dev/vdb或echo 1 > /sys/class/block/vdb/device/rescan - 对已有分区（
/dev/vdb1），先用fdisk /dev/vdb删除并重建分区（起始扇区不变，结束扇区拉到最大），再执行partprobe /dev/vdb - 若提示
device busy，且该分区已挂载，可尝试blockdev --rereadpt /dev/vdb（部分内核支持），或重启（最稳妥）
lsblk -f 显示 FSTYPE 为空或 unknown，说明 superblock 损坏或未格式化
扩容后 lsblk -f 的 FSTYPE 列为空、unknown，或 blkid 输出 TYPE=""，大概率是分区刚调完但还没写文件系统，或原有 superblock 损坏。此时 df 和 mount 必然失败。
- 先确认是否真没格式化：
sudo file -s /dev/vdb1—— 若输出含data或empty，说明无有效文件系统 - 若原为 ext4，且确定数据不要了，可重做：
sudo mkfs.ext4 -F /dev/vdb1（-F强制覆盖） - 若原为 XFS，用：
sudo mkfs.xfs -f /dev/vdb1（-f覆盖） - 切勿对已挂载分区执行
mkfs，否则直接丢数据
resize2fs 报错 “Bad magic number”，xfs_growfs 报错 “Invalid argument”，本质是类型不匹配
这两个错误都指向一个事实：你正在用 ext4 工具操作 XFS 分区，或反过来。扩容前必须确认真实文件系统类型，不能只看 /etc/fstab 或历史记录。
- 查真实类型优先用：
sudo blkid /dev/vdb1（输出TYPE="xfs"或TYPE="ext4"） - 辅助验证：
sudo xfs_info /dev/vdb1成功 → 是 XFS；sudo dumpe2fs -h /dev/vdb1 2>/dev/null | head -1输出含ext→ 是 ext 系列 - ext4 用
resize2fs /dev/vdb1（可在线）；XFS 必须用xfs_growfs /mount/point（参数是挂载点，不是设备路径） - 误用
resize2fs于 XFS 分区会破坏 superblock，恢复极难
扩容后空间“消失”：LVM、LUKS、RAID 层级被忽略
很多用户在 df -h 看到容量没变，就反复折腾 /dev/vdb1，却忘了它可能只是 LVM PV、LUKS 容器或 RAID 成员。真正的文件系统在上层逻辑设备里，底层扩容只是第一步。
- 先查结构：
lsblk看是否有lvm、crypt、raid标签；若有，df -h显示的挂载点对应的是/dev/mapper/xxx或/dev/mdX - LVM 场景：扩容物理卷后，要
pvresize /dev/vdb1→lvextend -l +100%FREE /dev/vg/lv→resize2fs /dev/vg/lv（或xfs_growfs /mount） - LUKS 场景：先
cryptsetup resize luks-name，再按内部文件系统类型扩容 - RAID 场景：扩完成员盘后，需
mdadm --grow /dev/md0 --size=max，再扩容文件系统
blkid 和 lsblk 验证当前层的真实状态，而不是依赖记忆或配置文件。
