Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When should I use /dev/shm/ and when should I use /tmp? Can I always rely on them both being there on Unices?

share|improve this question
up vote 40 down vote accepted

/dev/shm is a temporary file storage filesystem, i.e. tmpfs, that uses RAM for the backing store. It can function as a shared memory implementation that facilitates IPC.

Recent 2.6 Linux kernel builds have started to offer /dev/shm as shared memory in the form of a ramdisk, more specifically as a world-writable directory that is stored in memory with a defined limit in /etc/default/tmpfs. /dev/shm support is completely optional within the kernel config file. It is included by default in both Fedora and Ubuntu distributions, where it is most extensively used by the Pulseaudio application.

/tmp is the location for temporary files as defined in the Filesystem Hierarchy Standard, which is followed by almost all Unix and Linux distributions.

Since RAM is significantly faster than disk storage, you can use /dev/shm instead of /tmp for the performance boost, if your process is I/O intensive and extensively uses temporary files.

To answer your questions: No, you cannot always rely on /dev/shm being present, certainly not on machines strapped for memory. You should use /tmp unless you have a very good reason for using /dev/shm.

Remember that /tmp can be part of the / filesystem instead of a separate mount, and hence can grow as required. The size of /dev/shm is limited by excess RAM on the system and hence you're more likely to run out of space on this filesystem.

share|improve this answer
I will be using it to redirect output from a commands' standard error output to a file. Then I will read this file and process it. I will be doing this several thousand times (it's part of the condition of a loop construct). I thought memory would be nice in this case. But I also want it to be portable. I guess I'll check if /dev/shm exists, use it if it does, or fallback to /tmp. Does that sound good? – Deleted Sep 23 '09 at 16:04
I'd also add a check for the minimum size and current usage level of /dev/shm to guard against inadvertently filling it up. – nagul Sep 23 '09 at 21:01
Under Linux 2.6 and later the /dev/shm is required to be mounted for the POSIX shared memory system calls like shm_open() to work. In other words some programs will break if its not mounted - so it should be. It is not just a RAM disk. So you should make sure some of /dev/shm is free. – EdH Nov 30 '12 at 21:07
There is no performance boost by using /dev/shm. /dev/shm is memory (tmpfs) backed by the disk (swap). /var/tmp is memory (disk cache) backed by the disk (on-disk filesystem). In practice, performance is about the same (tmpfs has a slight edge but not enough to matter). /tmp may be tmpfs or not depending on how the administrator configured it. There is no good reason to use /dev/shm in your scripts. – Gilles Jun 18 '13 at 7:13
@GaretClaborn There's plenty of good reasons to use memory backed by swap, but that's called normal process memory. If you're using a file, it's called a filesystem, and all filesystems are memory (cache), which is backed by swap if the filesystem is something like tmpfs. Allocating disk space between swap and other storage areas is typically in the real of the administrator. If an application wants files that tend to remain in RAM, /tmp is the normal location (with $TMPDIR to override). The choice to make /tmp backed by swap, other disk space or nothing is the administrator's. – Gilles Jun 5 '14 at 14:09

Okay, here's the reality.

Both tmpfs and a normal filesystem are a memory cache over disk.

The tmpfs uses memory and swapspace as it's backing store a filesystem uses a specific area of disk, neither is limited in the size the filesystem can be, it is quite possible to have a 200GB tmpfs on a machine with less than a GB of ram if you have enough swapspace.

The difference is in when data is written to the disk. For a tmpfs the data is written ONLY when memory gets too full or the data unlikely to be used soon. OTOH most normal Linux filesystems are designed to always have a more or less consistent set of data on the disk so if the user pulls the plug they don't lose everything.

Personally, I'm used to having operating systems that don't crash and UPS systems (eg: laptop batteries) so I think the ext2/3 filesystems are too paranoid with their 5-10 second checkpoint interval. The ext4 filesystem is better with a 10 minute checkpoint, except it treats user data as second class and doesn't protect it. (ext3 is the same but you don't notice it because of the 5 second checkpoint)

This frequent checkpointing means that unnecessary data is being continually written to disk, even for /tmp.

So the result is you need to create swap space as big as you need your /tmp to be (even if you have to create a swapfile) and use that space to mount a tmpfs of the required size onto /tmp.

NEVER use /dev/shm.

Unless, you're using it for very small (probably mmap'd) IPC files and you are sure that it exists (it's not a standard) and the machine has more than enough memory + swap available.

share|improve this answer
Agreed, except for the conclusion, "NEVER use /dev/shm". You want to use /dev/shm in cases where you don't want a file to be written to the disk at all, and you want to minimize disk i/o. For example, I need to download very large zip files from an FTP server, unzip them, and then import them into a database. I unzip to /dev/shm so that for both the unzip and the import operations the HDD only needs to perform half the operation, rather than moving back and forth between source and destination. It speeds up the process immensely. That's one example of many, but I agree that it's a niche tool. – Nathan Stretch Dec 11 '14 at 23:13

Two slightly different aspects of your question that your answerers have emphasized differently:

  1. When to use /dev/shm, /tmp, or indeed /var/tmp, as a matter of good practice
  2. What sort of workload tmpfs is suitable for

Let's get the relation between these aspects straight:

│ /dev/shm │ always tmpfs │
│ /tmp     │ can be tmpfs │
│ /var/tmp │ never tmpfs  │

Good practices

(conservative edition)

  • When in doubt, use /tmp.
  • Use /var/tmp for large data that may not easily fit in ram.
  • Use /var/tmp for data that is beneficial to keep across reboots (like a cache).
  • Use /dev/shm as a side-effect of calling shm_open(). The intended audience is data buffers of bounded size that are overwritten frequently and endlessly.
  • If still in doubt, provide a way for the user to override. For example, the mktemp program honors the TMPDIR environment variable.

Where tmpfs excels

  • fsync is a no-op on tmpfs. This syscall is the number one enemy of (disk) performance (and flash longevity, if you care about that), though if defeating fsync is what you need tmpfs for, you are doing something wrong. Or, the developer behind that fsync call, I'd say. The eatmydata library exists for this very reason. If you are a user, suit yourself. If you are a developer, forget it, and stop making unnecessarily many small transactions! That is the real problem. Remember, all developers with blazing fast SSDs: it is not you who are bothered by this, by far.

How significant? Let me tell you my first fsync lesson: My previous job involved routinely "upgrading" a bunch of Sqlite databases (kept as testcases) to an ever-changing current format. The "upgrade" framework would run a bunch of scripts, probably making a few transactions each, to upgrade one database. Of course, I upgraded my databases in parallel (8 in parallel, since I was blessed with a mighty 8 core CPU). But as I found out, there was no parallelization speedup whatsoever (rather a slight hit) because the process was entirely IO bound. Hilariously, wrapping the upgrade framework in a script that copied each database to tmpfs, upgraded it there, and copied it back to disk was like 100 times faster (still with 8 in parallel). As a bonus, the PC was usable too, while upgrading databases.

  • Tmpfs lets you avoid ever flushing constantly changing files to disk, as if setting /proc/sys/vm/dirty_writeback_centisecs to infinity on a regular filesystem. This is appropriate when it is, and the proper use of tmpfs, but failing this is a much smaller concern than abusing fsync.

The writeback timeout has a default value of 5 seconds, meaning that an application will not be hindered from overwriting a file as frequently as it wants, in pagecache, but the content on disk is only updated about once every 5 seconds. Except if the application forces it through with fsync, that is. Think about how many times an application can output a small file in this time, compared to what a typical 7200 rpm harddisk can possibly take, (7200 transactions per minute (120 Hz) if nothing else is accessing it), and you see why it is those applications that insist on committing every single intermediate transaction to disk that really benefit from running on tmpfs.

What tmpfs can not help you with

  • Read performance. If your data is hot (which it better be if you consider keeping it in tmpfs), you will hit the pagecache anyway. The difference is when not hitting the pagecache, in which case you should consider that there is nothing that contemporary storage devices (be it harddisk or flash based) loves more than reading fairly sequential files out of a proper filesystem; swapping in 4KiB blocks is unlikely to be faster.
  • Short lived files. These are likely to live their entire lives in the pagecache (as dirty pages) before the /proc/sys/vm/dirty_writeback_centisecs timeout expires.

Where tmpfs sux

  • Keeping cold data. The least used data (coldest) are the most wasteful to keep in RAM, says the pagecache. Tmpfs replies: My pages are dirty — they need to be written somewhere (to swap) to be evicted from pagecache, as opposed to file backed clean pages that can be dropped in no time. Result: If your files are big and not the most constantly accessed memory in the machine, tmpfs is not the most efficient use of RAM, so if you don't have plenty to sacrifice, your machine will start swapping earlier, which is much worse than writing the files to a proper filesystem and be done with it.
share|improve this answer

Use /tmp/ for temporary files. Use /dev/shm/ when you want shared memory (ie, interprocess communication through files).

You can rely on /tmp/ being there, but /dev/shm/ is a relatively recent Linux only thing.

share|improve this answer
Isn't there a performance aspect as well? As /dev/shm is most often mounted as a tmpfs volume and essentially a RAM-disk? – Deleted Sep 23 '09 at 9:37
You can also mount /tmp as a tmpfs filesystem, I do so on my netbook to speed some things up by reducing writes to the (slow) SSD. There are disadvantages to doing so, of course (mainly the RAM use, but my netbook has far more RAM than it generally needs anyway). – David Spillett Sep 23 '09 at 10:55
For my specific case I would use it for a sort of process communication. I capture the output of standard error from an application and act on the contents (and I still need the standard output untouched, so I can't do any 1>/dev/null 2>&1. I would do this several thousand times so a tmpfs would be nice. However if I release the script I can't rely on tmpfs being used for /tmp as I think it's not that common. If it's more common for /dev/shm then that's better for me. But I'm looking for guidelines regarding portability etc. – Deleted Sep 23 '09 at 16:00

/dev/shm is used for shared virtual memory system specific device drivers and programs.

If you are creating a program that requires a virtual memory heap that should be mapped to virtual memory. This goes double so if you need multiple processes or threads to be able to safely access that memory.

The fact is that just because the driver uses a special version of tmpfs for it, doesn't mean you should use it as a generic tmpfs partition. Instead, you should just create another tmpfs partition if you want one for your temporary directory.

share|improve this answer

One more stab at the back of /dev/shm: As of 2014, its permissions got stricter, you need to go through loops to write to it if you are not root:

google: dev/shm permissions

share|improve this answer

In PERL, having 8GB minimum on any machine (all running Linux Mint), I am of what I think is a good habit of doing DB_File-based (data structure in a file) complex algorithms with millions of reads and writes using /dev/shm

In other languages, not having gigether everywhere, to avoid the starts and stops in network transfer (working locally on a file that is located on a server in a client-server atmosphere), using a batch file of some type, I will copy the whole (300-900MB) file at once to /dev/shm, run the program with output to /dev/shm, write the results back to the server, and delete from /dev/shm

Naturally, if I had less RAM, I would not be doing this. Ordinarily, the in-memory file system of /dev/shm reads as a size being one half of your available RAM. However, ordinary use of RAM is constant. So you really couldn't do this on a device with 2GB or less. To turn paraphrase to hyperbole, there is often things in RAM that even the system doesn't report well.

share|improve this answer
(I think this is in the spirit of what was originally asked.) What I mean basically is that I'm comfortable using /dev/shm as a RAM disk as long as I have sufficient memory. If it is inefficient to do so somehow, that should not dissuade you from doing so, but should trigger a question like "How can I have a ram disk on linux?". The answer is /dev/shm – David Grove Sep 27 '15 at 21:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.