Linux – How to find out what filesystem drivers are compiled-in into the linux kernel

filesystemskernel-moduleslinux-kernelprocsysfs

On a running linux system, what is a portable (among linux distributions) way to find out what filesystems the current kernel has compiled-in (not through modules) support for?

Consider for example my current Ubuntu x86_64 kernel: 3.11.0-24-generic #41-Ubuntu. It has for instance no /proc/config.gz, which would be my first thought otherwise.

The reason I'm interested is that I'd like to (programmatically) build a rescue environment with the current kernel and an initial ramdisk that the kernel will be able to load/mount.

Is is as simple as comparing /proc/filesystems with lsmod?

If so: Do the modules always have the exact same name (first column from lsmod output) as the filesystem name (last column in /proc/filesystems)?

Is there perhaps a more modern way such as /sys instead of /proc to look for info?

My current approach is as follows. Can someone confirm that it is correct, or advise how to do it instead?:

for fscand in $(awk '{print $NF}' /proc/filesystems)
do
  if test $(lsmod | grep -c -e '^'${fscand}'[^a-z0-9_-]') -eq 0
  then
    candlist="${fscand} ${candlist}"
  fi
done

for fscand in $candlist
do
  echo $fscand is compiled-in
done

Best Answer

Is is as simple as comparing /proc/filesystems with lsmod?

No:

$ comm -31 <(lsmod | awk 'NR!=1 {print $1}' |sort) \
           <(</proc/filesystems awk '{print $NF}' |sort) | fmt
anon_inodefs autofs bdev cgroup cpuset debugfs devpts devtmpfs ext2 ext3
fuseblk fusectl hugetlbfs mqueue nfs4 pipefs proc pstore ramfs rootfs
rpc_pipefs securityfs sockfs sysfs tmpfs

Many of these are not built into the kernel on that system. autofs is provided by a modules called autofs4 while nfs4 is provided by a module called nfs. The ext4 module provides ext2 and ext3 as well as ext4; fuse provides both fuseblk and fusectl. rpc_pipefs (not to be confused with pipefs) is provided by sunrpc.

Yet your system is able to load a module for a filesystem on demand: when you run mount -t foo …, if foo isn't a supported filesystem type, Linux attempts to load a module that provides this filesystem. The way this works is that the kernel detects that foo isn't a supported filesystem, and it calls modprobe to load a module called fs-foo. The mechanism is similar to pci:… aliases to load the driver for a PCI hardware peripheral by its PCI ID and usb:… which is similar to USB — see How to assign USB driver to device and Debian does not detect serial PCI card after reboot for more explanations. The fs-… module aliases are recorded in /lib/$(uname -r)/modules.alias. This file is generated when you build the kernel.

Under normal conditions, you can use this to determine which filesystems are provided by modules. By elimintation, the filesystems that are not provided by modules are built into the kernel. There are rare edge cases where this approach wouldn't work, for example if you've modified or erased your modules.alias file, or if a filesystem is provided both by a module and in a compiled-in form. I don't know of a way to cope with these cases short of writing some kernel code and loading it as a module.

for fs in $(</proc/filesystems awk '{print "fs-" $NF}' |sort); do
  /sbin/modprobe -n $fs 2>/dev/null || echo "$fs is built in"
done
Related Question