最权威的答案是读 /proc/filesystems——它不依赖模块是否已加载，直接反映内核编译时支持的所有类型，包括内置和可动态加载的文件系统；每行第二列是文件系统名，无 nodev 前缀的为真实块设备类型，如 ext4、xfs、vfat。
最权威的答案是读 /proc/filesystems —— 它不依赖模块是否已加载，直接反映内核编译时支持的所有类型。
怎么看内核原生支持哪些文件系统
/proc/filesystems 是内核启动时就确定的“能力清单”，包括内置和可动态加载的类型。它比 lsmod 或 ls /lib/modules/.../fs 更全面：后者只列模块文件，而有些文件系统（如 ext4）可能被编译进内核、不生成独立 .ko 文件，但依然会出现在 /proc/filesystems 里。
- 运行
cat /proc/filesystems，每行第二列就是文件系统名（如ext4、xfs、vfat） - 带
nodev前缀的是伪文件系统（proc、sysfs、tmpfs），不依赖块设备；没这个前缀的才是你插硬盘能用的真实类型 - 快速过滤真实类型：
awk '$1 != "nodev" {print $2}' /proc/filesystems - 注意 Alpine 等精简发行版常把部分类型（如
ntfs3）编译为模块而非内置，它们仍会出现在该文件中，但需modprobe才能启用
为什么 lsmod 不够用
lsmod 只告诉你“当前哪些模块已加载”，不是“系统支持什么”。比如 mount -t ntfs /dev/sdb1 /mnt 报 unknown filesystem type 'ntfs'，很可能只是 ntfs3 模块没加载，而不是内核不支持。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查已加载模块：
lsmod | grep -E '^(ext|ntfs|xfs|btrfs|f2fs|vfat)' - 重点看
Used by列：0 表示模块已加载但未被使用；非 0 表示正被某个挂载点占用 - 若某类型没出现，先试
sudo modprobe ntfs3；失败再用modinfo ntfs3确认模块是否存在、是否适配当前内核版本 - 别指望
ls /lib/modules/$(uname -r)/kernel/fs/覆盖全部——它漏掉内置类型，且某些发行版会删减模块目录
怎么验证某个设备实际用了什么文件系统
这不回答“系统支持什么”，但能反向验证内核是否有对应解析逻辑。尤其对未挂载设备，file -s 比 fdisk -l 可靠得多。
- 对未挂载分区运行：
sudo file -s /dev/sdb1 - 典型成功输出：
/dev/sdb1: Linux rev 1.0 ext4 filesystem data或SGI XFS filesystem - 如果输出
data或报cannot open，优先检查设备权限、是否被 LVM 或其他进程占用，再怀疑驱动缺失 -
fdisk -l只读分区表里的 type 字段（如0x83），不校验实际格式，误报率高，不能当真
别被 df -T 和 lsblk -f 带偏
这两个命令只显示“当前已挂载的类型”，不是“系统能支持什么”。比如你没挂过 btrfs 分区，df -T 就不会出现它，哪怕内核完全支持。
-
df -T的Type列只反映运行时状态，含伪文件系统（proc、tmpfs）和 FUSE 类型（fuse.sshfs） -
lsblk -f的FSTYPE列依赖 udev 和 blkid，若设备未被识别或标签损坏，可能为空或显示unknown - 想确认某个类型是否真可用，得组合判断：
/proc/filesystems有它 +modprobe能加载 +file -s能识别设备
真正容易被忽略的是同名文件系统的实现差异：比如旧内核的 ntfs 模块只读，新内核默认用 ntfs3；又比如带 casefold 特性的 ext4 在老内核里会被识别为 data —— 这时候 /proc/filesystems 显示支持，但实际无法挂载。
