Like tmpfs in Mac OSX

mount-ram.sh

#!/bin/sh

# This program has two feature.
#
# 1. Create a disk image on RAM.
# 2. Mount that disk image.
#
# Usage:
#   $0 <dir> <size>
#
#   size:
#     The `size' is a size of disk image (MB).
#
#   dir:
#     The `dir' is a directory, the dir is used to mount the disk image.
#
# See also:
#   - hdid(8)
#

mount_point=${1}
size=${2:-64}

mkdir -p $mount_point
if [ $? -ne 0 ]; then
    echo "The mount point didn't available." >&2
    exit $?
fi

sector=$(expr $size \* 1024 \* 1024 / 512)
device_name=$(hdid -nomount "ram://${sector}" | awk '{print $1}')
if [ $? -ne 0 ]; then
    echo "Could not create disk image." >&2
    exit $?
fi

newfs_hfs $device_name > /dev/null
if [ $? -ne 0 ]; then
    echo "Could not format disk image." >&2
    exit $?
fi

mount -t hfs $device_name $mount_point
if [ $? -ne 0 ]; then
    echo "Could not mount disk image." >&2
    exit $?
fi

umount-ram.sh

#!/bin/sh

# This program has two features.
#
# 1. Unmount a disk image.
# 2. Detach the disk image from RAM.
#
# Usage:
#   $0 <dir>
#
#   dir:
#     The `dir' is a directory, the dir is mounting a disk image.
#
# See also:
#   - hdid(8)
#

mount_point=$1
if [ ! -d "${mount_point}" ]; then
    echo "The mount point didn't available." >&2
    exit 1
fi
mount_point=$(cd $mount_point && pwd)

device_name=$(df "${mount_point}" 2>/dev/null | tail -1 | grep "${mount_point}" | cut -d' ' -f1)
if [ -z "${device_name}" ]; then
    echo "The mount point didn't mount disk image." >&2
    exit 1
fi

umount "${mount_point}"
if [ $? -ne 0 ]; then
    echo "Could not unmount." >&2
    exit $?
fi

hdiutil detach -quiet $device_name

This isn't quite the same. On Solaris (where tmpfs originated) and on FreeBSD (and probably also on Linux, but I don't know for certain), tmpfs is swap-backed. Memory pressure on the system will result in the contents of tmpfs getting pushed out to your on-disk swap partition. By way of contrast, what you've done above is to create a locked-in-memory ramdisk, which will not get swapped out, making that chunk of memory unavailable until the ramdisk is discarded.

Typically, such fixed ramdisks need to be fairly small, lest they exert their own significant memory pressure on the system, slowing it down in other ways. True tmpfs is much more flexible, as it will only keep your files in RAM opportunistically, but is willing to yield physical memory when the system is stressed, and will do so without losing the cached contents until the next reboot.

It's cool,I used a app name iramdisk for this.

tmpfs is not ramdisk.

Here's my take using hdiutil instead of hdid (deprecated) with mount, umount and orphan commands (and the device won't show up in Finder 😉): https://gist.github.com/Roman2K/3238fb441e298369198e

For anyone looking at RAM disks on recent macOS versions: tmpfs was recently introduced directly into the macOS kernel. Unlike the legacy hdiutil ram:// approach, native tmpfs dynamically scales RAM usage based on actual contents rather than pre-allocating a fixed block of memory.

The main limitation with native tmpfs is that unmounting or restarting completely purges the volume with no native persistence mechanism.

To solve this, I created RAM Folder (macOS 15+).
It hooks into macOS tmpfs while maintaining a bi-directional live sync between the RAM volume and the backing directory on disk on mount/unmount.
For anyone interested, you can try it for free on my website
Would love feedback from anyone testing it with heavy local dev caches or build scripts!