Wandering Thoughts archives

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.

LinuxManyVirtualFilesystems written at 23:20:04; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.