116

After seeing the comment by Anonymous on the question How is the /tmp directory cleaned up?, I found that it would be a great idea to implement on my system, since I have 16GB of RAM and I never used all of it.

My temporary files never get written to the disk. They get written to a RAM disk. I did put tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 in /etc/fstab.

My question is:

Can I set a maximum value for RAM Usage for /tmp? And in that case, what would happen if the maximum amount got exceeded, would it write into the hard-disk drive?

I have read a solution which states:

mkdir -p /tmp/ram
sudo mount -t tmpfs -o size=512M tmpfs /tmp/ram/

But in my understanding, this won't be a permanent solution. If I need it to be permanent, it has to be added to the /etc/fstab configuration file.

If this is the correct solution, how can I transform that mount command into a line in /etc/fstab?

Community
  • 1
Dan
  • 13,119

2 Answers2

103

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

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

Please note:

As tmpfs gets filled up, it will behave as any physical hard drive 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. In this case your computer will start to swap from ram to disk, which will make your system crawl to a halt, given you've got a swap partition to begin with, of course.

Considering this, a size of 512MB might be far too less nowadays, since much more ram is in existence in modern machines and it has become much cheaper. Since you've already 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

/var/cache

/var/games

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

Editorial note: I removed the /run in tmpfs mount option since this folder and its subfolders are already mounted in tmpfs by default.

willeM_ Van Onsem
  • 628
FuzzyQ
  • 2,328
  • 18
    If i'm not wrong, /var/tmp/ is for keeping files after reboot. Thats the main difference between this and /tmp/ , so YOU should not move /var/tmp to ram. –  May 27 '14 at 13:20
  • I checked that and you seem to be right. I scratched it from the answer. Thanks for clearing that up! – FuzzyQ May 27 '14 at 14:13
  • 2
    I'd add the nodev option also. – Mausy5043 Jun 12 '14 at 19:24
  • Thanks for the hint! I added security related mount options nosuid, nodev and noexec. – FuzzyQ Jun 13 '14 at 12:36
  • 5
    If Ubuntu runs out of 4GB tmpfs, will it use my 20GB SWAP partition? – loostro Jun 24 '14 at 16:30
  • 4
    Yes, I'll need to add this, too. As soon as tmpfs exeeeds its limits, it'll extend to swap partition (give there is one). – FuzzyQ Jun 24 '14 at 19:10
  • 10
    Does allocating half your RAM to this mean that half your RAM is reserved for the RAMDISK, or is it only a cap to what the RAMDISK may consume, and whatever is not in use is free RAM that gets assigned to whatever program needs RAM?? – matanox Jan 19 '15 at 15:01
  • 12
    @matt It's only a cap. – FuzzyQ Jan 19 '15 at 16:04
  • Thanks, that makes sense.. although, there'd be no automated warning in case the RAMDISK is becoming too full until it's too late, would there? – matanox Jan 19 '15 at 20:42
  • Even when your ram is depleted, it will replenish itself after a while. Your system will seem to crawl to a halt but it will recover with time. I wouldn't even bother to reboot since that might take even longer than to wait for the system to free up enough ram to run smoothly again. – FuzzyQ Jan 22 '15 at 15:15
  • 2
    You can use "fatrace" to see how much tmp activity there really is, and if this is worth it. – Bryce Mar 03 '15 at 02:21
  • 2
    adding noexec caused my netbeans 8.1 installation to fail. I take it by default /tmp does allow exec right? – Programster Nov 13 '15 at 07:51
  • Yes, it is mounted exec by default. Mounting it noexec is considered to be an additional layer of security, but it is also known to break some things from time to time. – FuzzyQ Feb 07 '16 at 15:25
  • 1
    When you put a /tmp line in /etc/fstab, the systemd-fstab-generator will end up creating /run/systemd/generator/tmp.mount , which you can then look at directly to see what's happening under the hood (and i.e. to compare against the version that Ubuntu ships in /usr/share/systemd). – Nathan Oct 19 '16 at 23:50
  • 2
    Q: why add the defaults option? If it's omitted, I'd assume that...the default options are being used anyway? – ckujau Mar 08 '17 at 05:37
  • 1
    @ckujau: In fact, the default option is completely unnecessary in this case. It's usually used as a placeholder for cases in which this field would be empty otherwise. I'm keeping it around in case I'd remove all other options. Only then would it be needed. – FuzzyQ Mar 10 '17 at 09:56
  • Could you add information on why nosuid should be used? – DarkTrick Oct 12 '20 at 05:30
  • 1
    If I'm not mistake, which I usually am, the system resorting to swap should have the same impact on performance as using the disk for /tmp to begin with since both scenarios depend on disk speed. Am I missing something here? – timuçin Jan 12 '21 at 14:02
  • @Dan yeah, that's my point. you cannot (in this specific context) go wrong with delegating memory for tmp – timuçin Oct 16 '21 at 01:06
59

On systems using systemd, you have the option of using a systemd unit file instead of fstab to accomplish the goal of using tmpfs to mount tmp. On my Ubuntu 16.04 system, I ran:

sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/tmp.mount
sudo systemctl enable tmp.mount
sudo systemctl start tmp.mount

The file /usr/share/systemd/tmp.mount looks like:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
[Unit]
Description=Temporary Directory
Documentation=man:hier(7)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime

[Install]
WantedBy=local-fs.target

Using FuzzyQ's fstab approach, systemd translates your fstab entries into mount units dynamically. I don't think either approach is better.

In order to set the maximum limit for the RAM as asked, one would need to add size=512M to the Options line, separated by a comma.

mapto
  • 329
  • 5
  • 13
Rick Ramstetter
  • 841
  • 3
    You will need systemctl enable tmp.mount after cp else systemctl will fail with message "Failed to start tmp.mount: Unit tmp.mount not found." – vimdude Oct 08 '16 at 18:17
  • 8
    @Rick, it's even better to use systemctl edit tmp.mount that would be distro-neutral. That puts your changes into override.conf so that you don't alter default tmp.mount and you could delete override.conf easily to go back to default configuration. –  Feb 05 '17 at 05:13
  • 3
    Ditto what Bulat said about using systemctl edit, and also use ln -s rather than cp in the first step. – Michael Gratton Jun 20 '19 at 02:28