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

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."

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.

/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.

> /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.

A past role in a past life had me installing security services on servers. One server had incredibly awkward permission sets across its common directories so our deployment script failed. The fix? Just throw it into /dev/shm and install it directly from there. It worked great.

"virtually every Unix system already has it mounted as a tmpfs by default" might be true if you say Linux instead, but Mac doesn't have /dev/shm

file-hierarchy(7) states /dev/shm is tmpfs and that "all users have write access to this directory", so I think you'd have to be making a non-systemd distro

/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.

"And it's been a long time, which agrees with this watch of mine"

I may misremember, but I think it's also common in the BSDs? (Whereas /var/tmp is persisted.)

This is a ridiculous comment but it did make me curious, when did /dev/shm become a common thing?

My current understanding is kernel 2.6, i.e. 2004.

It also says:

> Usually, it is a better idea to use memory mapped files in /run/ (for system programs) or $XDG_RUNTIME_DIR (for user programs) instead of POSIX shared memory segments, since these directories are not world-writable and hence not vulnerable to security-sensitive name clashes.

$XDG_RUNTIME_DIR usually points to /run/user/${uid}, so you're guaranteed that other users won't write there, and possibly won't even be able to read there.

/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.

2.4 in 2001 is when it was released with kernel support

I meant the author specifically wants to write files to RAM and nowhere else. There isn't a standard place for that.

> /tmp A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application.

It doesn't say anything about what it's backed by.

Mea culpa, you're right. I should not have assumed that just because POSIX was mentioned in the orbit of this thing that everyone else had this too.

The article has been corrected.

OS-X/macOS supports RAM drives and a script which defines one for use as /private/tmp (which /tmp is symbolically linked to) is:

  #!/bin/bash
  ramfs_size_mb=1024
  mount_point=/private/tmp
  
  counter=0
  ramfs_size_sectors=$((${ramfs_size_mb}*2048))
  ramdisk_dev=`hdiutil attach -nomount ram://${ramfs_size_sectors}`
  
  while [[ ! -d "/Volumes" ]]
  do
   sleep 1
   counter=$((counter + 1))
  
   if [[ $counter -gt 10 ]]
   then
    echo "$O: /Volumes never created"
    exit 1
   fi
  done
  
  diskutil eraseVolume HFS+ 'RAM Disk' ${ramdisk_dev} || {
   echo "$O: unable to create RAM Disk on: ${ramdisk_dev}"
   exit 2
  }
  
  umount '/Volumes/RAM Disk'
  
  mkdir -p ${mount_point} 2>/dev/null
  mount -o noatime -t hfs ${ramdisk_dev} ${mount_point} || {
   echo "$0: unable to mount ${ramdisk_dev} ${mount_point}"
   exit 3
  }
  
  chown root:wheel ${mount_point}
  chmod 1777 ${mount_point}

Adding a plist definition to /Library/LaunchDaemons can ensure the above is executed when the system starts.

/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.

Yeah, Mac is probably the odd one out, but it's also maybe the most common Unix-based/Unix-like desktop OS. Anyway, both are POSIX, unlike Linux.