Why Don't We Use More Ram Disks?

Why Don't We Use More Ram Disks?

Ram disks exist! We can leverage this for so many more workloads!

Many sticks of ram in a server.

Fig. 1. 200GB of Ram Pete a render farm shared in 2015 on Wikimedia
Source: Adapted from [1]

Scope

The overall topic of disks, storage, transfer protocols, file systems, and a whole host of other complexity surrounds this conversation. Today, I just want to focus on ram disks.

Disks in RAM?

Ram Disks are storage drives filesystems that can benefit some workloads but also come with some big draw backs. There are many situations where ram disks make a great deal of sense. Considering the cost of enterprise solid state storage disks, ram disks can help offset the marching write death to your solid state storage devices by taking a great deal of load off the device. We can use that to our advantage!

Ram-ification of Cost

At the time of this writing, ram has skyrocketed in cost due to market forces and neural network hype. If you didn’t have the foresight to load up on your own precious sticks of ram prior to this event, there is no need for fomo. This is not the first time that sharp price increases have happened on memory and trends usually come back down to earth within a year or two. Unlike GPU’s that have inspired versatility in many unexpected technology breakthroughs, memory is necessary for every device, it’s a commodity. My recommendation, fiddle today, and then build this knowledge in as a serious tool that you might leverage for the future.

Why would I want to do this?

👍 Pros (Advantages)👎 Cons (Drawbacks)
Increased Speed: Minimal seek time (ideal for random I/O).Volatile Data: Data is lost immediately on power loss or reboot.
Reduced Wear: No physical writes to permanent storage media.Limited Capacity: Constrained by the amount of physical RAM available.
Easy Setup: Often configurable with a single command (tmpfs in Linux).Memory Contention: Uses up system RAM needed by other applications.
Silent Operation: Zero noise (useful for quieter homelab!).No Error Correction: Potential for silent data corruption (less common).

What about ECC RAM?

Hey big spender! ECC (Error Correcting Code) memory absolutely provides some error correction and mitigates that risk. If ECC is available to you? Great! If not, the consequences should not be serious given that we should only choose ram disks for data that we aren’t serious about storing long term. I use ECC myself in some applications of my homelab but that does not influence my excitement or fear toward potential applications for ram disks in the least.

The golden rule I want to install in you with is this. We never use RAM disks for data we care about preserving even if it’s just for a short period.

Sequential vs Random Access

It’s important to recognize what kinds of tasks may warrant your limited amount of memory available. To understand that better, we don’t have to be silicon scientists, but we do have to have a layman’s understanding of how data makes its way onto a device. We’re going to go back to some basics here for the people in the back.

Sequential Access

This is similar to writing a letter. Letters get written in a linear fashion until the work is completed. Just like writing data clusters on a hard drive. Data is written to disk cylinders on file storage in order as neat little blocks. Think about copying a large file from one disk to another without any fancy network protocol optimization. I send one byte, you store one byte, I send the next byte etc. This is what may make mechanical hard disks the ideal choice for sequential archival data because of the lower cost per gigabyte and there are benefits to reading sequential data more quickly even on mechanical disks. Similar to the needle of a record player, hard drives benefit from staying in a groove and reading data in order. Solid state storage is also excellent for reading at higher speeds than mechanical hard drives but you can’t beat that lower cost of storing a lot of data.

graph TD
    subgraph Sequential Access
        A[Start Write] --> B(Data Block 1)
        B --> C(Data Block 2)
        C --> D(Data Block 3)
        D --> E(Data Block 4)
        E --> F[Finished]
    end

    style B fill:#66BB6A,stroke:#388E3C,stroke-width:2px;
    style C fill:#66BB6A,stroke:#388E3C,stroke-width:2px;
    style D fill:#66BB6A,stroke:#388E3C,stroke-width:2px;
    style E fill:#66BB6A,stroke:#388E3C,stroke-width:2px;

Random Access

When we talk about random access writing to storage devices. There is typically a lookup table that provides the position information and some fancy functions. For our purposes, think of it as similar to seeking information on a table of contents for a large document. You may have to return to that table of contents several times for seeking random information throughout the document. In short, random access takes additional time and “thinking” to recall data.

graph TD
    subgraph Random Access
        G[Start Write] --> H(Data Block A)
        H --> I(Jump/Lookup Required!)
        I --> J(Data Block B)
        J --> K(Jump/Lookup Required!)
        K --> L(Data Block C)
        L --> M[Finished]
    end

    style H fill:#66BB6A,stroke:#388E3C,stroke-width:2px;
    style I fill:#0178d4,stroke:#388E3C,stroke-width:2px;
    style J fill:#66BB6A,stroke:#388E3C,stroke-width:2px;
    style K fill:#0178d4,stroke:#388E3C,stroke-width:2px;
    style L fill:#66BB6A,stroke:#388E3C,stroke-width:2px;

    classDef jump fill:#FFEB3B,stroke:#FBC02D,stroke-width:2px;
    class I,K jump;

Practical Implementation (Beginner)

On Linux this is fairly straight forward. We can create a temporary drive that doesn’t survive reboots. First we create a mount point folder and then assign it as our ram disk using the tmpfs file system.

Basic 10 Megabyte Ram Disk
sudo mkdir /mnt/ramdisk
sudo mount -t tmpfs -o size=10M tmpfs /mnt/ramdisk

We can check that the drive exists and its free space by running the following:

Disk Free Human Readable Command
sudo df -h

Practical Implementation (Intermediate)

We can take this even further by using feature flags. Here’s a quick summary of what is commonly available.

tmpfs Filesystem Mount Options

The tmpfs filesystem supports the following mount options:

OptionValue Syntax/ExampleDescription
size=bytessize=4g, size=256m, size=80%Specifies an upper limit on the size of the filesystem. Given in bytes, rounded up to pages. Suffixes k, m, g are supported (KiB, MiB, GiB). A % suffix limits it to a percentage of physical RAM. Default is size=50%.
nr_blocks=blocksnr_blocks=100mSpecifies the upper limit in blocks, where a block is PAGE_CACHE_SIZE. Suffixes k, m, g are supported. Percentage (%) suffix is not supported.
nr_inodes=inodesnr_inodes=1mThe maximum number of inodes for this instance. Suffixes k, m, g are supported. Percentage (%) suffix is not supported.
mode=modemode=0755Set initial permissions of the root directory.
gid=gidgid=1000Set the initial group ID of the root directory (Since Linux 2.5.7).
uid=uiduid=1000Set the initial user ID of the root directory (Since Linux 2.5.7).
noswapnoswapDisables swap for this instance. (Since Linux 6.4). By default, swap is enabled. Remounts must respect the original settings.
huge=huge_optionhuge=always, huge=adviseSet the huge table memory allocation policy for all files (if CONFIG_TRANSPARENT_HUGEPAGE is enabled).
mpol=mpol_optionmpol=bind:0-3,5, mpol=interleaveSet the NUMA memory allocation policy for all files (if CONFIG_NUMA is enabled). (Since Linux 2.6.15).

Details on Complex Options

Huge Page Policy (huge=huge_option)

Requires CONFIG_TRANSPARENT_HUGEPAGE to be enabled.

huge_optionDescription
neverDo not allocate huge pages. (Default)
alwaysAttempt to allocate huge pages every time a new page is needed.
within_sizeOnly allocate huge pages if they will be fully within i_size. Respects fadvise(2) and madvise(2) hints.
adviseOnly allocate huge pages if explicitly requested with fadvise(2) or madvise(2).
denyEmergency option to force the huge option off from all mounts.
forceForce the huge option on for all mounts (useful for testing).

NUMA Memory Policy (mpol=mpol_option)

Requires CONFIG_NUMA to be enabled. nodelist is a comma-separated list of nodes (e.g., 0-3,5,7).

mpol_optionDescription
defaultUse the process allocation policy (see set_mempolicy(2)).
prefer:nodePreferably allocate memory from the given node.
bind:nodelistAllocate memory only from nodes in the specified nodelist.
interleaveAllocate from each available node in turn.
interleave:nodelistAllocate from each node in the specified nodelist in turn.
localPreferably allocate memory from the local node.

My Recommendation for Most Situations

Extended Command With Higher Security
sudo mkdir /mnt/ramdisk/
sudo mount -t tmpfs -o defaults,noexec,nosuid,nodev,size=10M tmpfs /mnt/ramdisk/

tmpfs Mount Options Used

Here is a table of the options broken down that take advantage of both the mount and tmpfs options. This offers additional security. Read the table below.

FieldValueDescription
Filesystem (Device)tmpfsSpecifies the filesystem type is tmpfs (Temporary Filesystem), which is an in-memory, volatile filesystem backed by RAM and Swap.
Mount Point/mnt/ramdisk/The directory where the tmpfs will be mounted. Files saved here are stored in memory.
Filesystem TypetmpfsConfirms the filesystem type is tmpfs.
Mount Optionsdefaults,noexec,nosuid,nodev,size=100GA comma-separated list of options:
defaultsIncludes the standard options: rw (read/write), suid, dev, exec, auto, nouser, and async. (Note: Some of the following options override the defaults).
noexecSecurity: Does not allow execution of binaries in this filesystem, preventing a user from uploading and running malicious executable files.
nosuidSecurity: Prevents SUID (Set User ID) and SGID (Set Group ID) bits from taking effect, which blocks unprivileged users from gaining elevated permissions.
nodevSecurity: Does not interpret character or block special devices, preventing users from creating and exploiting device nodes (like /dev/null) within the mount.
size=1GLimit: Sets the maximum size this tmpfs instance can grow to. It will use up to $100$ Gigabytes of system RAM and/or Swap space.
Dump Flag0Specifies the filesystem should not be backed up by the dump utility.
Pass Number0Specifies the filesystem should not be checked by fsck at boot time.

Make This Disk (Not Data) Persistent Across Reboots

Modify fstab Boot Configuration
sudo nano /etc/fstab
FSTAB /etc/fstab
# Our 1GB ram disk accesed in /mnt/ramdisk folder
tmpfs /mnt/ramdisk/ tmpfs defaults,noexec,nosuid,nodev,size=1GB,mpol=local 0 0

WIP I’ll return to show some more advanced examples and real world situations. I have run low on memory at the moment to continue this.

References

[1] User:Pete, "200GB of Ram Pete a render farm shared in 2015 on Wikimedia," *Wikimedia* 2015. [Online]. Available: https://commons.wikimedia.org/wiki/File:Project_365_-322-_181115_Memories..._(22500113713).jpg Accessed: Dec. 11, 2025.