tmpfs is a Linux filesystem that stores all of its files and directories in virtual memory instead of on a block device. Data lives in the kernel’s page cache and can be moved to swap under memory pressure, so a tmpfs mount is extremely fast but volatile: its contents disappear when it is unmounted or the system reboots.
Within the Linux filesystem landscape, tmpfs serves as the standard home for short-lived data such as runtime state in /run, shared memory in /dev/shm and, on many distributions, temporary files in /tmp. It grows and shrinks with its contents up to a configurable size limit, and it uses memory only for data that is actually stored.
How tmpfs stores files in memory
tmpfs is built on the kernel’s shared memory (shmem) subsystem. A file on tmpfs consists of pages in the page cache with no backing file on disk. When the kernel needs memory, it can write those pages to swap space, just like anonymous process memory, and read them back on access.
Because there is no disk structure to maintain, tmpfs needs no formatting, no journal and no fsck. Metadata such as inodes and directory entries exists only in kernel data structures, which makes creating, renaming and deleting files very cheap.
| Location | When data is there | Access speed |
|---|---|---|
| RAM (page cache) | Normal operation | Memory speed |
| Swap space | Under memory pressure | Disk or SSD speed |
| Nowhere | After unmount or reboot | Data is lost |
Mount options and size limits
A tmpfs filesystem is created with a simple mount command such as mount -t tmpfs -o size=2G tmpfs /mnt/scratch or an entry in fstab. If no size is given, the default limit is half of physical RAM. The limit is a ceiling, not a reservation: an empty tmpfs consumes almost no memory.
| Option | Meaning | Example |
|---|---|---|
| size | Maximum size in bytes, units or percent of RAM | size=512M or size=25% |
| nr_inodes | Maximum number of inodes | nr_inodes=1M |
| mode | Permissions of the root directory | mode=1777 for /tmp |
| uid and gid | Owner of the root directory | uid=1000,gid=1000 |
| noexec, nosuid, nodev | Security restrictions | Common for /tmp and /dev/shm |
| huge | Use of transparent huge pages | huge=within_size |
The size of an existing mount can be changed online with mount -o remount,size=4G /mnt/scratch. Setting the limit larger than RAM plus swap is allowed but dangerous, because filling it can exhaust memory and trigger the OOM killer.
Typical uses of tmpfs on Linux systems
Modern distributions mount several tmpfs instances automatically through systemd. Each serves data that should never survive a reboot, which also avoids stale lock files and sockets after a crash.
| Mount point | Contents | Notes |
|---|---|---|
| /run | PID files, sockets, runtime state | Required early in boot |
| /dev/shm | POSIX shared memory objects | Used for inter-process communication |
| /tmp | Temporary files | tmpfs by default on some distributions |
| /run/user/UID | Per-user runtime directory | Created at login, removed at logout |
| /sys/fs/cgroup | Control group hierarchy root | Pseudo filesystems mounted beneath |
Beyond system directories, administrators use tmpfs for build directories, test databases, browser caches and scratch space for data processing. Containers rely heavily on it as well: container runtimes mount tmpfs for secrets and writable scratch areas so that sensitive data is never written to disk.
tmpfs compared with related filesystems
tmpfs is often confused with older or similar mechanisms. The key distinctions are whether the size is limited, whether swap is used and whether data persists.
| Option | Backing storage | Size limit | Persistence |
|---|---|---|---|
| tmpfs | Page cache and swap | Yes, configurable | Lost at unmount |
| ramfs | Page cache only, never swapped | No limit | Lost at unmount |
| RAM disk (brd) | Fixed block device in RAM | Fixed at creation | Lost at reboot, needs a filesystem |
| zram | Compressed block device in RAM | Fixed at creation | Lost at reboot |
| ext4 or XFS | Disk or SSD | Device size | Persistent |
ramfs is simpler but riskier, since a process can fill it until the machine runs out of memory. A classic RAM disk wastes memory by double caching, because data sits in the block device and again in the page cache. tmpfs avoids both problems, which is why it replaced them for almost all purposes. In OverlayFS setups, tmpfs often serves as the writable upper layer for live systems.
Performance and monitoring
The speed advantage of tmpfs is largest for metadata-heavy workloads, such as creating and deleting many small files, where disk filesystems spend time on journaling and synchronous writes. For large sequential reads of data already in the page cache, the difference from a disk filesystem is smaller, because Linux caches disk data in memory as well.
Usage is visible with ordinary tools. df -h shows the used and available space of each tmpfs mount, while the Shmem field in /proc/meminfo reports the total memory held by tmpfs and shared memory together. Monitoring both values helps administrators notice a slowly filling mount before it competes with applications for memory.
Recent kernels add further controls, such as user and group quotas on tmpfs and support for extended attributes, which make it more suitable for multi-user systems where one account should not be able to fill a shared /tmp.
Risks and common mistakes
- Storing irreplaceable data on tmpfs, forgetting that a reboot or crash erases it.
- Oversizing mounts, so that one runaway process can consume most of RAM and swap.
- Ignoring memory accounting: tmpfs pages count as shared memory and can be charged to a cgroup, which may trigger container limits unexpectedly.
- Placing huge downloads in /tmp on systems where /tmp is tmpfs, causing no space left errors.
- Assuming tmpfs never touches disk: with swap enabled, contents can be written to swap unless swap is encrypted or disabled.
In simple terms
tmpfs is a folder that lives in the computer’s memory instead of on its disk. Reading and writing there is very fast, because memory is much quicker than any drive.
The trade-off is simple. When the computer restarts, everything in that folder is gone, like writing on a whiteboard that is wiped clean every night. That makes tmpfs perfect for temporary notes and scratch work, and a poor place for anything worth keeping.
A practical example
A development team runs a continuous integration server with 64 GB of RAM that compiles a large C++ project many times a day. Builds write tens of thousands of small object files, and the SSD shows heavy wear and long I/O waits. An administrator adds a tmpfs mount with size=24G for the build directory in fstab.
Because object files are created and deleted constantly, they now stay in memory. Typical build times drop noticeably, often by a significant fraction for this kind of workload, and SSD writes fall sharply. Build artifacts that must be kept are copied to persistent storage at the end of each job.
The team also caps parallel jobs so that peak memory use stays below physical RAM. The outcome is faster, more predictable builds with no risk of losing anything important when the server restarts.