先确认内核是否已重读分区表，fdisk -l 能看到新容量但 df -T 仍显示旧大小，说明分区表未刷新，需运行 partprobe /dev/sda 或 blockdev --rereadpt /dev/sda，否则 resize2fs 或 xfs_growfs 均无效。
扩容后 df -T 不显示新空间？先确认内核是否已重读分区表
扩容操作（如虚拟机磁盘调大、云盘在线扩容）完成后，fdisk -l 能看到新容量，但 df -T 仍显示旧大小，大概率是内核还在用旧分区表。这不是文件系统没识别，而是底层设备信息未刷新。
必须让内核重新加载分区信息，否则后续所有操作（包括 resize2fs 或 xfs_growfs）都会失败或无效果：
- 对传统 MBR 分区：运行
partprobe /dev/sda（替换为你的设备名），成功时无输出；失败时提示device busy，说明有进程正访问该盘（如挂载中、lsof 查进程），需先处理 - 对 GPT 分区或某些内核版本（≥ 5.0），
partprobe可能不生效，改用blockdev --rereadpt /dev/sda - 若仍不识别，重启是兜底方案——但生产环境应尽量避免，优先排查
lsblk输出中分区节点是否已更新
lsblk -f 显示 FSTYPE 为空？说明文件系统尚未创建或损坏
lsblk -f 是最直观的“一眼诊断”命令：它不依赖挂载状态，直接读取设备 superblock。如果扩容后某分区（如 /dev/sda2）的 FSTYPE 列为空，意味着两种可能：
- 你只扩大了分区，但没在新空间上扩展文件系统（例如执行了
fdisk扩分区，却漏掉resize2fs /dev/sda2或xfs_growfs /mount/point） - 分区虽扩大，但文件系统元数据损坏或未格式化（比如误删了 superblock，或扩容前文件系统已处于
clean以外的状态） - 此时别急着写数据，先用
e2fsck -n /dev/sda2（ext4）或xfs_repair -n /dev/sda2（xfs）做只读检查，确认一致性
为什么 blkid 和 file -s 结果不一致？优先信 file -s
blkid 缓存 superblock 信息，有时扩容后未及时更新（尤其刚跑完 mkfs 或 resize2fs 就立刻查），会返回旧 TYPE 或空值；而 file -s /dev/sda2 直接扫描设备二进制头，更接近“物理事实”。
典型冲突场景：
-
blkid显示TYPE="ext4"，但file -s输出Linux rev 1.0 ext3 filesystem data→ 实际仍是 ext3，扩容前未升级文件系统，resize2fs可能拒绝操作 -
blkid无输出，file -s显示SGI XFS filesystem→ 文件系统存在，但 UUID 损坏或blkid缓存失效，可尝试blkid -p /dev/sda2强制探测 - 两者都为空，但
lsblk显示该设备有分区 → 很可能是 LVM、LUKS 或 RAID 层，需用pvs/cryptsetup status进一步下钻
扩容后挂载点 df -T 类型显示 unknown？检查内核模块是否加载
当 df -T 在挂载点行显示 Type 为 unknown，且 mount | grep sda2 显示类型也是 unknown，问题不在分区或文件系统本身，而在内核缺少对应文件系统驱动。
常见于：
- XFS 文件系统但
xfs.ko模块未加载：运行modprobe xfs，再lsmod | grep xfs确认；若报错Module not found，需安装kmod-xfs（CentOS/RHEL）或linux-image-extra-$(uname -r)（Ubuntu） - Btrfs 分区被识别为
unknown：同理检查btrfs.ko，注意部分精简内核（如某些容器宿主机）默认不编译 btrfs 支持 - 使用了较新的文件系统（如 erofs、f2fs），但系统内核版本过低（如 CentOS 7 默认不支持 f2fs）→ 升级内核或换用兼容方案
真正麻烦的是那种“lsblk -f 有类型、df -T 显示 unknown、但 mount 命令又能成功挂载”的情况——这往往意味着挂载时用了非标准选项（如 loop 或 bind），得查 /proc/mounts 第四列确认真实类型。
