a pseudo-filesystem (procfs/sysfs, tmpfs)

Not everything that looks like a file is backed by bytes on a disk. When you read /proc/cpuinfo and see your CPU model, or read /sys/class/net/eth0/statistics/rx_bytes and see a live packet count, you are using the file interface - open, read, write - to talk to the kernel itself, not to stored data. Filesystems that present non-disk things as files are pseudo-filesystems, and they are one of the most elegant ideas in Unix: everything is a file, so kernel state, devices, and even temporary RAM storage can all be reached with the same familiar tools.

There are two flavours to distinguish. Synthetic/information pseudo-filesystems like procfs (mounted at /proc) and sysfs (mounted at /sys) contain no stored data at all; each file is generated on the fly. When you open() and read() /proc/meminfo, the kernel runs a function that produces the current memory statistics as text right then - there is no /proc on any disk, and nothing persists across a reboot. procfs exposes per-process and system information (one numbered directory per running process, plus global files), while sysfs exposes the device and driver model as a navigable tree. By contrast, tmpfs is a real, read-write filesystem that stores actual files - but in RAM (backed by the page cache and swap) rather than on disk, which is why /tmp or /dev/shm on tmpfs is fast and why everything in it vanishes on reboot. All of these plug into the kernel through the same VFS interface that real disk filesystems use; they simply implement the file operations by computing or by using memory instead of reading blocks.

Why it matters: pseudo-filesystems are how a huge amount of system inspection and control happens with ordinary commands - cat /proc/loadavg to see load, echo a value into a /sys file to change a device setting, df to watch a tmpfs fill up. The honest cautions: a procfs/sysfs file is not a stored value but a live view computed at read time, so two reads can differ and the size reported by stat is often meaningless (frequently zero). And tmpfs counts against RAM (and swap), so a runaway write to /dev/shm can pressure memory just like any other allocation - it is fast precisely because it is not really on disk, with all the durability consequences that implies.