Mastering ramfs and tmpfs: Deep Dive into Linux’s High‑Speed In‑Memory Filesystems

1. Kernel Memory Management Basics

Linux’s virtual memory (VM) subsystem provides each process with an independent virtual address space that the MMU maps to physical memory. The VM includes modules for allocation/recovery, page‑table management, and cache management, handling page faults and swapping pages to disk when needed.

Physical memory offers fast access, while swap space on disk serves as a backup when RAM is insufficient. Typical swap size is 1–2 × the RAM, but high‑performance servers may reduce swap to minimise latency.

2. Introduction to Memory File Systems

A memory file system stores data directly in RAM instead of on a disk, giving nanosecond‑level latency. Compared with traditional disk‑based file systems (e.g., ext4, XFS) that suffer mechanical delays, memory file systems provide dramatically faster reads and writes.

Common types include:

tmpfs : flexible, can use both RAM and swap, dynamically grows/shrinks with file usage.

ramfs : simple, uses only physical RAM, no size limit, suitable for real‑time scenarios.

Other variants such as initramfs for early boot and memory‑based database filesystems (e.g., Redis AOF).

3. tmpfs Storage Mechanism

3.1 Implementation Principles

tmpfs resides in the fs/tmpfs directory of the kernel source. Its superblock private data is defined by struct tmpfs_sb_info, which tracks size limits, inode limits and current usage.

struct tmpfs_sb_info {
    struct shmem_sb_info sbinfo;   // shared‑memory base info
    unsigned long max_size;        // maximum memory limit
    unsigned long max_inodes;      // maximum inode count
};

Each file’s inode is represented by struct tmpfs_inode_info, extending the generic VFS inode with page indexing and shmem links.

struct tmpfs_inode_info {
    struct inode vfs_inode;   // standard VFS inode
    pgoff_t i_pagedir;        // file page index
    struct page *i_private;   // private data page
};

tmpfs implements the VFS file‑operation interface, allowing standard calls such as open, read, write, mmap and fsync:

const struct file_operations tmpfs_file_operations = {
    .read  = generic_file_read,
    .write = generic_file_write,
    .mmap  = tmpfs_mmap,
    .fsync = noop_fsync,
};

3.2 Memory Allocation and Reclamation

When a file is written, the kernel allocates a tmpfs_inode_info and then obtains physical pages from the page cache. For example, writing 1 MiB results in 256 pages of 4 KiB each:

struct page *page = alloc_page(GFP_HIGHUSER);
if (page) {
    page->mapping = inode->i_mapping;
    page->index   = offset;
}

During deletion, truncate_inode_pages(inode->i_mapping, 0) frees the pages, returning them to the global free‑page pool.

3.3 Size and Inode Limits

Mount options control resource usage. Example to limit tmpfs to 1 GiB: # mount -t tmpfs -o size=1G tmpfs /mnt/tmpfs When the limit is reached, further writes fail with ENOSPC. The nr_inodes option caps the number of inodes, preventing exhaustion by many small files.

3.4 Interaction with Swap

If memory is scarce, the VM may page out inactive tmpfs pages to swap:

// page out to swap
pageout(page, mapping);
SetPageSwapCache(page);
page->private = swap_entry;

Accessing a swapped‑out page triggers a page‑fault; the kernel reads the page back from swap:

// read page back from swap
swap_readpage(page);

4. ramfs Storage Mechanism

4.1 Implementation Principles

ramfs relies solely on physical memory and the page cache. When a file is created, the kernel allocates an inode and a directory entry, linking the path to the inode.

static const struct inode_operations ramfs_inode_ops = {
    .lookup = ramfs_lookup,
    .create = ramfs_create,
    .unlink = ramfs_unlink,
};
static const struct file_operations ramfs_file_ops = {
    .read_iter  = generic_file_read_iter,
    .write_iter = generic_file_write_iter,
};

Read/write operations occur entirely within the page cache; data never leaves RAM.

4.2 Memory Allocation Characteristics

ramfs allocates contiguous physical pages when possible, falling back to multiple blocks if necessary:

struct page *ramfs_alloc_page(gfp_t gfp)
{
    return alloc_pages(gfp, 0);
}

Because ramfs never uses swap, data remains in RAM until the file is deleted or the system reboots.

4.3 Risks of Unlimited Size

Without a built‑in size cap, ramfs can consume all free RAM, leading to OOM (Out‑Of‑Memory) conditions, process termination, and system instability. Proper monitoring and cleanup are essential.

5. Application Scenarios

5.1 Typical ramfs Use‑Cases

Embedded devices (e.g., smart cameras, speakers) where fast boot and real‑time response are critical.

Temporary high‑speed data caches such as real‑time stock‑price analysis, where data lives only for the process lifetime.

5.2 Typical tmpfs Use‑Cases

System /tmp directory for transient files, benefiting from automatic cleanup on reboot.

Large‑scale data‑processing pipelines that need dynamic memory allocation and can fall back to swap under pressure.

Web services, log aggregation, and session caches that require fast access but can tolerate eviction.

6. Practical Cases

6.1 ramfs Mounting and Usage

# create mount point
mkdir -p /mnt/ramfs_test
# mount ramfs (no size limit)
mount -t ramfs ramfs /mnt/ramfs_test

Embedded scripts can add the same command to /etc/rc.local for automatic mounting at boot.

6.2 tmpfs Mounting and Usage

# limit to 512 MiB
mount -t tmpfs -o size=512M tmpfs /mnt/tmpfs_demo

# limit size and inode count
mount -t tmpfs -o size=1G,nr_inodes=200000 tmpfs /mnt/tmpfs_file

The default /tmp directory is already a tmpfs mount, providing automatic cleanup after reboot.

6.3 Memory‑Overflow and Performance Optimisation

ramfs can cause OOM if unchecked; therefore, size hints, monitoring scripts, and periodic cleanup are recommended. For tmpfs, choosing an appropriate size avoids excessive swapping, and adding noatime reduces unnecessary metadata writes.

# optimise /tmp mount
mount -t tmpfs -o size=512m,noatime tmpfs /tmp

Combining large‑file aggregation, inode management, and timely deletion keeps both filesystems performant.