←back to thread

Save your disk, write files directly into RAM with /dev/shm

(hiandrewquinn.github.io)
62 points hiAndrewQuinn | 1 comments | 26 Jun 25 23:04 UTC | HN request time: 0s | source
Show context
hackyhacky ◴[26 Jun 25 23:38 UTC] No.44392515[source]▶
Rather than re-write your scripts to store temp files into /dev/shm, you can just mount /tmp using the tmpfs file system and get the same benefit for all your programs. Some distros do this by default.

The relevant line from fstab is:

    tmpfs /tmp            tmpfs    noatime 0       2
Now any program that writes to /tmp will be writing to a RAM disk, thus sparing unnecessary wear on my SSD.
replies(7): >>44392526 #>>44392690 #>>44392745 #>>44392789 #>>44392847 #>>44393129 #>>44393836 #
hiAndrewQuinn ◴[26 Jun 25 23:40 UTC] No.44392526[source]▶
I do mention this offhand in the article: "The existence of /dev/shm is a boon for me mostly because it means I never have to worry about whether /tmp is really RAM-based again."
replies(2): >>44392561 #>>44392655 #
quotemstr ◴[26 Jun 25 23:45 UTC] No.44392561[source]▶
Now you have to worry about whether you can access /dev/shm. Please encourage people to use supported interfaces instead of random voodoo (anything under /dev that wasn't there in 1995) for day-to-day tasks.
replies(2): >>44392587 #>>44392713 #
hiAndrewQuinn ◴[26 Jun 25 23:49 UTC] No.44392587[source]▶
/dev/shm is typically world-writable by default:

    $ ls -ld /dev/shm
    drwxrwxrwt 3 root root 120 Jun 32 02:47 /dev/shm/
Incidentally, "30 years ago" is the cutoff date for music being considered the oldies. This just made me realize Nevermind is now an oldie, and soon The Lonesome Crowded West will be too.
replies(3): >>44392630 #>>44392642 #>>44392682 #
quotemstr ◴[26 Jun 25 23:59 UTC] No.44392630[source]▶
> /dev/shm is typically world-writable by default:

You are relying on random implementation details instead of universal APIs that work across OSes and environments. Please stop.

So help me God, if I make a Linux system, I will make it _not_ have a /dev/shm just to avoid people relying on non-standard stuff for no good reason. Honestly, it's because of stuff like this that we need Docker.

replies(3): >>44392650 #>>44392659 #>>44392663 #
frollogaston ◴[27 Jun 25 00:06 UTC] No.44392663[source]▶
/tmp isn't a standard place for RAM disk either, all it says is: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.htm...

I'm not really seeing a right or wrong here anyway unless you're distributing a script that's meant to run on all sorts of Linux systems. In which case you probably aren't concerned with the physical storage medium being used.

replies(1): >>44392723 #
quotemstr ◴[27 Jun 25 00:16 UTC] No.44392723[source]▶
/tmp is literally POSIX:

https://pubs.opengroup.org/onlinepubs/9799919799/

It doesn't get more standard than that.

It's because of people doing random nonstandard shit that we need to Docker-ize a lot of software these days. People refuse to lift a single finger to adhere to conventions that let programs co-exist without simulating a whole god damn computational universe for each damn program.

replies(3): >>44392751 #>>44392770 #>>44392902 #
1. fluidcruft ◴[27 Jun 25 00:51 UTC] No.44392902{3}[source]▶
/tmp is not specified to be a RAM disk by POSIX. Just that things in there are considered to be not persistent after a program stops (with implications for backups and disaster recovery). Sure, RAM disks work if the amount of /tmp space you need is less than your free physical RAM but sometimes that's not the case, either.

Back in the day you might place /tmp in a good spot for random access of small files on a disk platter. /var is vaguely similar but intended for things that need to be persistent.

Anyway it's not uncommon for systems to persist /tmp and clean it periodically from cron using various retention heuristics.

Ultimately POSIX concepts of mountpoints are strongly tied to optimizing spinning rust performance and maintenance and not necessarily relevant for SSD/NVME.