Mount /tmp in RAM

I’ve heard one can put /tmp in RAM to save SSD writes. I have an SSD and in addition to saving writes I’m also short on space. I have 16GB of RAM and was wondering if theres a guide on setting this up, Thank You.

Hello and welcome here.

Please, allways tell us which version of openSUSE you use. We can not guess that.

Oh, I’m sorry. OpenSUSE 13.1 with KDE on a System 76 Galago UltraPro.

Core I7-4750HQ
Intel Iris Pro 5200
240GB Intel 525
Intel Centrino N

13.1 is still not released (won’t be long though).
Thus this belongs in the Pre-release/Beta forum and will be movedd there. This is CLOSED for the moment.

I found this answer:

You are absolutely right. The according fstab entry would look like this:

**tmpfs /tmp tmpfs defaults,noatime,mode=1777,nosuid,size=512M 0 0**

Please note:

As tmpfs gets filled up, it will behave as any physical harddrive by giving an “not enough space” error. While rebooting (and thus emptying the cache) will fix this, you may run into trouble when a single operation consumes more space to begin with than there’s space on tmpfs.

Considering this, a size of 512MB might be far too less nowadays. Since you’ve got 16GB of ram, using the default value of half your ram for tmpfs should more than suffice for almost all scenarios. To use the default value, simply leave out the size=512M entry in your /etc/fstab file.

Another note:

You can quite as easily mount other system folders into ramdisk as well, such as


/run (use mode=0755 instead of mode=1777)



/var/log/apt (use only defaults,noatime without mode= or nosuid)

But beware: the same rules apply as above, running out of space might cause major trouble. E.g. imagine running out of space for /var/log/apt will render you unable to install any programs! Furthermore, loading /var/log folders into ramdisk will delete all your log files upon reboot, so you won’t be able to debug your system if anything unexpected happens. So use these settings at your own risk!

But you need to be careful here . I have a bash script to edit your fstab file you can find here:

SYSEdit - System File Editor - Version 1.50 - Blogs - openSUSE Forums

Thank You,

Moved from Applications and open again.

On 2013-11-14 17:26, hcvv wrote:
> Moved from Applications and open again.

On 2013-11-14 17:58, Ken Schneider wrote:> On 11/14/2013 11:16 AM, hcvv
pecked at the keyboard and wrote:

> Doesn’t this question also apply to earlier versions? Why so quick to
> move questions for 13.1 to “pre-release” when the release date is only 5
> days out? Just asking.

This area in particular changes between versions, it depends on what
they have changes on systemd.

The upstream systemd in 12.3 assumed that /tmp was a tmpfs, but openSUSE
changed that, leaving the traditional “real” directory. This has effects
on how to delete automatically files in tmp.

13.1 is supposed to correct some bugs in this area, so its treatment of
/tmp should be different. There is a greater chance that the people that
read the beta forum are aware of these than the rest of the
correspondents :slight_smile:

Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Thank You very much for the answer. What is the difference between /tmp and /var/tmp?

Also, instead of “size=512M” could I use “size=4G” or would I have to use “size=4096M” ?

I guess that depends on how they are used by software.

The more-or-less tradition is that “/tmp” is for short term temporary files, while “/var/tmp” is for temporary files that should persist beyond the current boot (such as editor save files, for example).

OK I added the line to my fstab with the excellent SYSEdit minus the size parameter. Is there a way to mark this thread as solved?

Is there a way to check that its working?

Will this close off half my RAM to the rest of my system like an HDD partition, or will it use it as needed?

On 2013-11-14 22:56, Autonomous Penguin wrote:
> Is there a way to mark this thread as solved?


> Is there a way to check that its working?

Reboot, try “mount” and “df -h”.

Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I don’t think so. You lose only what is actually in use. And I think some of that can overflow to swap, if there is a problem.

I’ve been using tmpfs swap for several years on some of my systems. It has worked well. I’m doing it mainly so that anything committed to disk will be encrypted (I use encrypted swap).

The output of “df” should tell you if there is a mounted “/tmp”.

devtmpfs 7.9G 16K 7.9G 1% /dev
tmpfs 7.9G 96K 7.9G 1% /dev/shm
tmpfs 7.9G 5.8M 7.9G 1% /run
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
tmpfs 7.9G 52K 7.9G 1% /tmp
tmpfs 7.9G 5.8M 7.9G 1% /var/lock
tmpfs 7.9G 5.8M 7.9G 1% /var/run

Looks like its good to go, Thank You!

You might want to check out the tmpfs documentation;
It states not to exceed 1/2 your ram or it will dead lock your system.

Thanks, that will make a good read. By omitting the size parameter it should default to half my RAM, and it appears to have done so.

I notice alot of mention of Swap, I don’t have Swap. Do you think that could cause any issues?

On 2013-11-14 23:26, Autonomous Penguin wrote:

> I notice alot of mention of Swap, I don’t have Swap. Do you think that
> could cause any issues?

Oh, yes. Absolutely.

Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

It doesn’t actually say that, at least as I a reading it.

It does warn about oversizing, but it does not say what is oversizing. And the discussion does seem to imply that it is memory+swap, rather than just memory that matters.

size: The limit of allocated bytes for this tmpfs instance. The
default is half of your physical RAM without swap. If you
oversize your tmpfs instances the machine will deadlock

Indeed, you can set the size of a tmpfs as large as you want, even larger than the size of physical memory plus swap. You can also set the size to zero, which is interpreted as “unlimited”. As for the result of actually trying to use that much space – well, you are hereby invited to try that on your own system. I don’t care to do it on mine.

It can make a lot of sense in plausible situations to make the tmpfs far larger than physical ram. But it is hard to come up with a situation in which it makes sense for the tmpfs to be larger than ram plus swap. (I know you were just saying it is possible, not that it makes sense. I just wanted to distinguish larger than ram from larger than ram+swap).