tmpfs vs ramfs: What's the Difference?

By LinuxCert.Guru Team·

Objective

This guide explains tmpfs and ramfs clearly, from how they work to when each is appropriate, with the exact commands used in production and on the RHCSA exam. By the end, you will know:

  • What tmpfs and ramfs actually are and how they differ from each other
  • Where RHEL already uses tmpfs by default, and why that matters
  • How to mount, size, and persistently configure a tmpfs filesystem
  • The one critical difference between tmpfs and ramfs that makes ramfs dangerous to use without understanding
  • Where these topics connect to RHCSA exam objectives around filesystems, fstab, and storage

You already have in-memory filesystems running on your RHEL system right now, whether you know it or not. Understanding what they are, how they behave, and how to manage them deliberately is the difference between a sysadmin who knows the commands and one who understands what the system is actually doing.

What In-Memory Filesystems Are

Both tmpfs and ramfs store their contents in RAM rather than on a physical disk. Reads and writes happen at memory speed, which is orders of magnitude faster than any storage device. That speed comes with one absolute constraint: everything stored on them is lost when the system reboots or when the filesystem is unmounted.

This makes them unsuitable for anything that needs to survive a reboot, but ideal for:

  • Temporary files created and discarded during a process run
  • Build artifacts, test data, and compilation output that would otherwise hammer a disk
  • Session-level caches where persistence isn't needed and speed is critical
  • System-level runtime data the kernel needs fast access to

tmpfs and ramfs look similar from the outside. Underneath they behave differently in ways that matter enormously when you're managing a production system.

tmpfs vs ramfs: The Difference That Actually Matters

This is the most important section in this guide. Most content on this topic lists the differences without making clear which one is the dangerous one. Here it is plainly:

  • tmpfs has a size limit. You set a maximum when you mount it. When that limit is reached, writes fail with an out-of-space error. The system stays stable.
    • Under memory pressure, tmpfs data can be swapped out to disk, freeing RAM for other processes
    • You can see tmpfs usage with df -h because it exposes a known size to the kernel
  • ramfs has no size limit and cannot be swapped. It grows without bound as you write to it, consuming RAM until the system runs out entirely.
    • When RAM is exhausted, the OOM (Out of Memory) killer activates and starts terminating processes to free memory
    • On a production system, an unchecked ramfs can bring down the entire server
    • ramfs does not appear in df -h output, because the kernel doesn't know how large it is

The practical conclusion is straightforward: use tmpfs for almost everything. ramfs exists for specific situations where you absolutely cannot allow the data to be swapped to disk, for example, certain cryptographic operations where sensitive key material must never touch persistent storage under any circumstances. Outside of those narrow cases, tmpfs is the right choice.

One sentence to remember: tmpfs can run out of space. ramfs can run out of memory. Running out of space is recoverable. Running out of memory often isn't.

Where RHEL Already Uses tmpfs

Before you mount any tmpfs manually, understand that RHEL already uses it for several critical system directories by default. You can see this immediately after boot:

# See all currently mounted filesystems including tmpfs
df -hT | grep tmpfs

# Or use mount to see the full list
mount | grep tmpfs

Typical output on a fresh RHEL 10 system:

tmpfs          tmpfs   7.7G     0  7.7G   0% /dev/shm
tmpfs          tmpfs   1.6G  9.4M  1.6G   1% /run
tmpfs          tmpfs   7.7G     0  7.7G   0% /sys/fs/cgroup
tmpfs          tmpfs   1.6G     0  1.6G   0% /run/user/1000

What these directories are used for:

  • /dev/shm: shared memory for inter-process communication. Applications that use POSIX shared memory write here. Size is typically half of total RAM by default.
    • Databases, messaging systems, and high-performance applications frequently use this
  • /run: runtime data for services, PID files, sockets, and lock files that need to exist while the system is running but not after a reboot
    • This replaced /var/run, which used to be a regular directory. On modern RHEL, /var/run is a symlink to /run.
  • /sys/fs/cgroup: the cgroup filesystem used by systemd and container runtimes for resource management
  • /run/user/UID: per-user runtime directories, created at login and cleaned up on logout

This is worth understanding for the RHCSA because it means tmpfs isn't an obscure specialty tool. It's woven into how every RHEL system runs, and recognizing it in df output is a basic administrative skill.

Mounting tmpfs Manually

Basic Mount

# Create a mount point
mkdir -p /mnt/ramdisk

# Mount a 512MB tmpfs
mount -t tmpfs -o size=512M tmpfs /mnt/ramdisk

# Verify it's mounted and the size is correct
df -hT /mnt/ramdisk

Mount with Multiple Options

# Mount with size limit, set permissions, and noexec for security
mount -t tmpfs -o size=1G,mode=1777,noexec tmpfs /mnt/tmpdata

# Common mount options:
# size=    maximum size (supports K, M, G suffixes, or percentages like size=25%)
# mode=    permissions on the root of the filesystem (e.g. 1777 like /tmp)
# uid=     owner UID of the mount root
# gid=     owner GID of the mount root
# noexec   prevent execution of binaries stored here
# nosuid   ignore SUID/SGID bits on files stored here

Resizing a Mounted tmpfs

Unlike disk-based filesystems, you can resize a tmpfs while it's mounted without unmounting it first:

# Increase the size of an existing tmpfs mount to 2GB
mount -o remount,size=2G /mnt/ramdisk

# Verify the new size
df -hT /mnt/ramdisk

Making tmpfs Persistent Across Reboots

This is where the RHCSA exam connection is clearest. tmpfs data is always lost on reboot, but the mount itself can be made persistent through /etc/fstab, so the empty filesystem is automatically recreated at boot and available for use.

# Add this line to /etc/fstab for a persistent 1GB tmpfs mount
vim /etc/fstab
tmpfs   /mnt/ramdisk   tmpfs   defaults,size=1G   0 0
# Test the fstab entry without rebooting
mount -a

# Verify it mounted correctly
df -hT /mnt/ramdisk

# Verify the fstab syntax is valid (critical before rebooting)
mount --fake -a -v

The fstab column breakdown for this entry:

  • tmpfs: the device field, by convention tmpfs mounts use "tmpfs" as the device name, though any label works since there's no actual device
  • /mnt/ramdisk: the mount point, which must already exist
  • tmpfs: the filesystem type
  • defaults,size=1G: mount options, always specify size here or the default is half of total RAM
  • 0 0: dump and fsck pass, both zero because an in-memory filesystem needs neither

Exam note: An fstab entry with a typo can prevent the system from booting cleanly. Always validate with mount -a after editing fstab. This applies to every filesystem type, not just tmpfs, and is tested implicitly in any RHCSA task that involves persistent mounts.

Mounting ramfs

The command structure is identical to tmpfs, but the size option is ignored:

# Mount a ramfs (no size limit enforced)
mkdir -p /mnt/ramfs
mount -t ramfs ramfs /mnt/ramfs

# Note: ramfs does not appear in df output the same way
# It will show 0 bytes used and 0 bytes available
df -hT /mnt/ramfs

Because ramfs has no enforced limit, never mount it without a process-level guarantee that writes to it are bounded. For production use, tmpfs with an explicit size is almost always the correct choice.

Practical Production Use Cases

  • Build systems and CI pipelines:
    • Mount a tmpfs at the build output directory
    • Compilation writes thousands of intermediate object files, all to RAM instead of disk
    • Build times can drop significantly, especially on systems with slower storage
    • The output directory clears automatically when the build container or session ends
  • Database temporary tables and sort space:
    • Databases like MySQL and PostgreSQL write temporary sort files during large query operations
    • Pointing tmpdir at a tmpfs mount eliminates the disk I/O entirely for those operations
    • Critical: size your tmpfs larger than the maximum expected temporary table size or queries will fail with out-of-space errors
  • Log buffering for high-throughput applications:
    • Write logs to tmpfs and flush to disk periodically rather than writing every line to disk synchronously
    • Acceptable when losing a few seconds of logs in a crash is tolerable
    • Not appropriate when log completeness is required for compliance or forensics
  • Shared memory for IPC:
    • /dev/shm is already tmpfs, but you may need to resize it for memory-intensive applications
    • PostgreSQL, Oracle, and some messaging systems need /dev/shm larger than the default half-RAM

Resizing /dev/shm for Application Requirements

This is a real production task that comes up frequently and connects directly to fstab management:

# Check current /dev/shm size
df -hT /dev/shm

# Resize immediately (runtime only)
mount -o remount,size=4G /dev/shm

# Make the resize persistent via fstab
vim /etc/fstab
tmpfs   /dev/shm   tmpfs   defaults,size=4G   0 0
# Apply and verify
mount -o remount /dev/shm
df -hT /dev/shm

tmpfs, ramfs, and the RHCSA Exam

Being precise here matters, the same way it did for kpatch and Quadlet earlier in this series.

tmpfs and ramfs are not listed as standalone exam objectives on the official RHCSA 10 blueprint. The exam focuses on storage management through LVM, partitions, swap, and persistent filesystem configuration. However, in-memory filesystems connect directly to topics that are explicitly tested:

  • Reading and interpreting df output, where tmpfs mounts appear alongside real filesystems and you need to recognize them
  • Writing correct fstab entries, which is the same skill whether you're mounting XFS on a logical volume or tmpfs in RAM
  • Understanding filesystem types, since the exam expects you to be comfortable with the full range of what Linux can mount, not just block device filesystems
  • The persistence model, the concept that data loss on reboot is expected for some filesystem types, connects directly to the exam's constant emphasis on what survives a reboot and what doesn't

Where this pays off most in an exam context: if a task involves /dev/shm, /run, or any path that shows up as tmpfs in df output, you need to know immediately that this is an in-memory filesystem and what that means for the task at hand. That recognition doesn't come from memorizing a list of filesystem types, it comes from understanding what tmpfs actually is.

Common Mistakes

  • Not specifying a size when mounting tmpfs. Without a size option, tmpfs defaults to half of total system RAM. On a server with 64GB RAM, an unsized tmpfs can grow to 32GB before you get an error. Always set size= explicitly.
    • This applies to fstab entries as well, don't write defaults and leave out the size
  • Confusing tmpfs data loss with a bug. If files stored in /run or /dev/shm disappear after a reboot, that's correct behavior, not an error. Data on any tmpfs is intentionally ephemeral.
  • Using ramfs where tmpfs would work. There is almost never a good reason to use ramfs in a general administration context. If you're not working on cryptography or a kernel-level use case that explicitly requires it, use tmpfs.
  • Forgetting to create the mount point before mounting. Unlike some tools, mount won't create a missing directory for you. mkdir -p /mnt/ramdisk first, always.
  • Setting a tmpfs size larger than available RAM plus swap. If the mount point fills to its configured maximum and the system has already exhausted RAM and swap, the result is the same as running out of memory entirely. Size it to what you actually need, not to the maximum you might ever conceivably use.
  • An invalid fstab entry for a tmpfs mount. A typo in the options column can prevent the system from booting normally into the correct target. Test every fstab change with mount -a before rebooting.

Conclusion

tmpfs and ramfs are not obscure tools. tmpfs is already running on your RHEL system before you do anything, powering /run, /dev/shm, and other critical system directories. Understanding what they are is understanding part of how Linux itself works.

  • tmpfs has a size limit and can swap to disk, making it safe and predictable for production use
  • ramfs has no size limit and cannot swap, making it capable of consuming all RAM without warning
  • Use tmpfs in almost every situation, always with an explicit size= option
  • Persistent tmpfs mounts belong in /etc/fstab exactly like any other filesystem, always validate with mount -a
  • For RHCSA, the skills that matter here are fstab syntax, df output interpretation, and understanding which data survives a reboot and which doesn't

The data in RAM is always gone when the system reboots. The mount configuration in fstab is not. Keep that distinction clear and in-memory filesystem tasks, whether on the exam or in production, become straightforward.

Start practicing RHCSA storage and filesystem labs at LinuxCert.Guru → https://linuxcert.guru

$_
Ready to go beyond reading?Practice with free, auto-graded RHCSA labs.
Start free →