I set up a RAM disk on Linux with one line of code and my apps have never loaded faster

After setting up a quick Linux build, my system still felt a bit off. This wasn’t a case of crashing programs nor the regular bugs you expect on a fresh setup. Things were just a second slower than I would like. Installs seemed to drag, and I saw minor delays during routine tasks. This was a bit puzzling because I had low RAM usage and my SSD was fine.

So, I decided to change how my system handles constant small reads and writes by switching to a RAM disk, which required a single fstab entry and redirecting some high-activity folders. It’s the most instant I have ever seen a system go from lagging to fast.

Where a RAM disk actually makes a difference

It’s not about everything—it’s about the right kind of workload

When you use a RAM disk, you are effectively treating a section of your memory like a storage drive. It’s not just a technique for improved raw speed. It actually dramatically reduces latency, especially for workflows that require frequent small-file reads and writes.

Modern SSDs can be very fast, and with improved tech like NVMe SSDs, they could even get better. However, you still may experience some delay when they have to handle thousands of small operations. This is the exact scenario where a RAM disk can make a difference, and moving any of the file types listed below can yield the biggest gains:

• Browser cache (the single most noticeable improvement)
• Compilation and build directories
• Temporary or scratch-heavy app data

I avoid including persistent files I care about and large media or storage-heavy data in my RAM disk. Here is the rule of thumb: systems that do small repetitive I/O work well on a RAM disk.

The one-line setup that just works

The exact fstab entry and what each part does

Setting up a RAM disk on my Linux Mint system requires this single line in /etc/fstab:

tmpfs /mnt/ramdisk tmpfs defaults,noatime,nosuid,nodev,size=2G 0 0

You can open and edit the fstab file by running this command on your Linux terminal: sudo nano /etc/fstab

With this, you are set up, and these are the parts of this code that actually matter:

• tmpfs: Tells Linux to use a RAM-backed filesystem
• /mnt/ramdisk: Where it will be mounted
• noatime: Prevents unnecessary write operations
• size=2G: Caps how much RAM it can use

On a RAM disk, atime updates generate metadata writes on reads; noatime disables those updates, reducing unnecessary write overhead.

The size you use is more practical than theoretical. On this system, I have 16GB of RAM, so I can safely allocate between 1 and 4GB. Ultimately, you want to allocate enough to make it useful, but not so much that it makes it harder for running apps to function.

Before rebooting your system, test the RAM disk by running this command:

sudo mount -a

Then use this command to confirm that it’s active:

df -h | grep ramdisk

Now your file system should be fast and ready for use, even though nothing is using it at this point.

The step that actually makes the difference

Symlinking your app’s cache folder

A mounted RAM disk is doing nothing until apps start writing to it. You must direct specific folders to it. The best way to achieve this is using symlinks, and it’s a two-step process:

1. Move the existing cache folder to your RAM disk
2. Create a symbolic link pointing back to the original location

For Chrome, for instance, the two steps will be running the commands below:

mv ~/.cache/google-chrome /mnt/ramdisk/Default/Cache /mnt/ramdisk/chrome-cache
ln -s /mnt/ramdisk/chrome-cache ~/.cache/google-chrome/Default/Cache

While these commands are the equivalent for Firefox:

mv ~/.cache/mozilla /mnt/ramdisk/
ln -s /mnt/ramdisk/mozilla ~/.cache/mozilla

After running these commands, every Chrome and Firefox cache read/write will now happen in RAM and not your traditional disks. But because the RAM disks are wiped on a reboot, you must note these:

• Cache folders will need to be recreated
• Symlinks must still point to a valid location

This is a repetitive task that you can automate on Linux. I specifically like using a small startup script, but a tool like profile-sync-daemon may be a more elegant way of handling browser profiles in RAM.

Some things became instant — others didn’t move at all

Once I made this change, my browser felt instantly faster. And this was not just launch speed but everything else, including restoring tabs, loading cached pages, and switching between sessions. I timed a few tasks to see if the difference was tangible:

As long as something relied heavily on cache or temporary writes, I saw real improvements. I even saw improved installation speed because metadata and small-file operations were completed more efficiently. Build processes were also smoother and more consistent, even though not necessarily faster. I was registering fewer pauses and waiting times between steps.

However, before you switch to a RAM disk, you should know it trades persistence for speed, so a crash or shutdown will erase the data. I recommend starting small (1–2GB). Also, avoid including anything you can’t afford to lose. A well-configured RAM disk is a practical way of getting better performance on your device.