2024-04-19
Modern Linux mounts a lot of different types of virtual filesystems
For reasons that don't fit in the margins of this entry, I was recently looking at the filesystems that we have mounted on our Ubuntu machines and their types. Some of these filesystems are expected and predictable, such as the root filesystem (ext4), any NFS mounts we have on a particular machine (which can be of two different filesystem types), maybe a tmpfs mount with a size limit that we've set up, and ZFS filesystems on our fileservers. But a modern Linux system doesn't stop there, and in fact has a dizzying variety of virtual filesystems on various mount points, with various different virtual filesystem types.
As of Ubuntu 22.04 on a system that boots using UEFI (and runs some eBPF stuff), here is what you get:
sysfs /sys proc /proc devtmpfs /dev devpts /dev/pts tmpfs /run securityfs /sys/kernel/security tmpfs /dev/shm tmpfs /run/lock cgroup2 /sys/fs/cgroup pstore /sys/fs/pstore efivarfs /sys/firmware/efi/efivars bpf /sys/fs/bpf autofs /proc/sys/fs/binfmt_misc hugetlbfs /dev/hugepages mqueue /dev/mqueue debugfs /sys/kernel/debug tracefs /sys/kernel/tracing fusectl /sys/fs/fuse/connections configfs /sys/kernel/config ramfs /run/credentials/systemd-sysusers.service binfmt_misc /proc/sys/fs/binfmt_misc rpc_pipefs /run/rpc_pipefs tracefs /sys/kernel/debug/tracing tmpfs /run/user/<UID>
That amounts to 20 different virtual filesystem types, or 19 if you don't count systemd's autofs /proc/sys/fs/binfmt_misc mount.
On the one hand, I'm sure all of these different virtual filesystem types exist for good reason, and it makes the life of kernel code simpler to have so many different ones. On the other hand, it makes it more difficult for people who want to exclude all virtual filesystems and only list 'real' ones. For many virtual filesystems and their mounts, the third field of /proc/self/mounts (the type) is the same as the first field (the theoretical 'source' of the mount), but there are exceptions:
udev devtmpfs systemd-1 autofs none ramfs sunrpc rpc_pipefs
(On another system there is 'gvfsd-fuse' versus 'fuse.gvfsd-fuse' and 'portal' versus 'fuse.portal'.)
As a pragmatic matter, for things like our metrics system we're probably better off excluding by mount point; anything at or under /run, /sys, /proc, and /dev is most likely to be a virtual filesystem of some sort. Alternately, you can rely on things like metrics host agents to have a sensible default list, although if you have to modify that list yourself you're going to need to keep an eye on its defaults.
PS: technically this is a mix of true virtual filesystems, which materialize their files and directories on demand from other information, and 'virtual' filesystem types that are merely purely RAM-based but do store inodes, files, and directories that you create and manipulate normally. Since the latter are ephemeral, they usually get lumped together with the former, but there is a core difference. And a virtual filesystem isn't necessarily volatile; both 'efivarfs' and 'pstore' are non-volatile.