A Linux host has a tmpfs filesystem mounted at /dev/shm whose size is reported as half the machine's RAM. What kind of storage is tmpfs, what does that size figure actually mean, and what happens to files written into it?

## What tmpfs actually is Most filesystems are a layout imposed on a block device: ext4 on `/dev/sda1`, XFS on an LVM logical volume. tmpfs has no device. It is a filesystem implemented directly on top of the kernel's virtual-memory subsystem — its file contents are pages of memory, indexed by the same page cache machinery that caches disk files, but with nothing on disk to write them back to. That single fact explains every property people find surprising about it. Because the pages are anonymous-but-shared rather than file-backed, the kernel accounts them as shared memory. You can watch a tmpfs grow directly: ``` grep -E 'Shmem|SwapTotal' /proc/meminfo dd if=/dev/zero of=/dev/shm/blob bs=1M count=256 grep Shmem /proc/meminfo ``` `Shmem` climbs by 256 MiB. No block device is touched. ## The size figure is a ceiling, not a reservation If you mount a tmpfs without options, the kernel's default limit is half of physical RAM. That is a limit, not a claim: a freshly mounted 8 GiB tmpfs consumes essentially nothing. Memory is charged page by page as files are written, and released when files are deleted or truncated. `size=` and `nr_inodes=` set the caps explicitly, and both accept `k`, `m` and `g` suffixes: ``` mount -t tmpfs -o size=512m,nr_inodes=10k tmpfs /mnt/scratch ``` When a tmpfs hits its cap, writes fail with `ENOSPC` — a normal "no space left on device" error, even though the disk is empty. That is the good outcome. The bad outcome is the one people forget: a tmpfs mounted with a generous limit is a legitimate way for an application to consume all of the machine's memory while looking, from `df`, like an ordinary filesystem filling up. ## Swap, and the difference from ramfs tmpfs pages can be written to swap when the system is under memory pressure. That means tmpfs is not a guarantee of RAM-speed access, and it is not a guarantee that data never touches a disk — a subtlety that matters when someone stores secrets or key material in `/dev/shm` and assumes it can never be persisted. On a machine with swap, it can be, unless the swap device itself is encrypted. The older `ramfs` is the opposite bargain: it cannot be swapped and it accepts no size limit, so a runaway writer fills memory until the machine becomes unusable. tmpfs was created precisely to add the size cap and the swap escape hatch, which is why practically everything you meet on a modern system is tmpfs. ## Why dropping caches does not free it A common misconception is that because tmpfs lives "in the cache", the kernel will reclaim it under pressure the way it reclaims cached file data. It cannot. A cached page of an ext4 file has a clean copy on disk, so the kernel can simply drop it. A tmpfs page has nowhere to be dropped to — the filesystem *is* the memory. `echo 3 > /proc/sys/vm/drop_caches` will not shrink a tmpfs by a single byte. The only ways memory comes back are deleting the files or swapping the pages out. ## Where you already have one `/dev/shm` is the mount POSIX shared memory is built on: `shm_open()` creates a file there, and processes map it to share memory. On systemd hosts, `/run` is a tmpfs holding volatile runtime state — PID files, sockets, generated configuration — which is why it is empty again after a reboot. Several distributions also mount `/tmp` as tmpfs. Container runtimes use tmpfs mounts for the same reason, to give a workload scratch space that cannot outlive it. ## When to reach for one The honest use cases are scratch space with a short life and an appetite for IOPS — build intermediates, test fixtures, unpacked archives, caches you would rather rebuild than persist — and data you specifically do not want left on the disk after the process exits. The disqualifier is durability: anything that must survive a crash, and anything larger than you are willing to lose from the machine's memory budget, belongs on a real filesystem. ## What the interviewer is checking They want to hear that you read `df` output for a tmpfs as a memory number, not a storage number. A candidate who says "the /dev/shm mount is 90% full, so we're about to run out of RAM" has understood it. A candidate who says "it's fine, that's just disk" has not.