Consider the practice of mounting the /tmp directory on a tmpfs memory based filesystem, as can be done with: systemctl enable tmp.mount

And consider the following:

one justification: The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.


another justification: Some applications writing files in the /tmp directory can see huge improvements when memory is used instead of disk.

Is disk caching always in effect? By that I mean when you write to any folder (not just /tmp) you are probably writing to RAM anyway until such time it gets flushed to disk... the kernel handles all this under the hood and it is my opinion I don't need to go meddling tweaking things. So does doing systemctl enable tmp.mount has any real value, if so what?

Also (in CentOS-7.6) I am testing this to try and understand what's happening I am experiencing:

  • CentOS 7.6 installed on one 500GB SSD with simple disk partitioning as
    • 1GB /dev/sda1 as /boot
    • 100MB /dev/sda2 as /boot/efi
    • 475GB /dev/sda3 as /
  • PC has 8GB of DDR-4 RAM
  • if I do just systemctl enable tmp.mount I then get
    • 3.9GB tmpfs as /tmp

How is this tmpfs /tmp at 3.9GB any better than the default way which would (a) first have up to ~8GB based on RAM thanks to disk caching and (b) then when disk caching at capacity based on 8GB of RAM there is > 400GB of disk available to use ?

2 Answers 2


Whether this configuration "adds value" depends entirely on the use-case in question. "Good", "bad", these are not valid labels for different configuration options without context.

For systems with a lot of RAM and high transaction numbers, the tmpfs filesystem would probably increase performance (example: a Type-2 hypervisor). This might be "good" use case.

Alternatively, systems with a small amount of ram but plenty of storage (example: any of the Internet-of-Things crap made these days) probably perform better with physically written /tmp storage devices, since anything in memory can be written to swap if underutilized (if swap is activated as well). This could be considered a "bad" case for tmpfs /tmp.


When you mount a path with tmpfs, the default size is half of physical memory. Any files you place there will be in memory and will not touch disk as long as your system is not under memory pressure.

This is in contrast to writing to a file on actual persistent storage (like spinning disk, ssd, or nvme). If you had 500GB of memory free and you did open-write-close of 1GB to a file on spinning disk, the kernel would do a few things for you:

  • the kernel would buffer the writes for you
  • if your filesystem were journaling (e.g., most filesystems used today, like ext4, xfs, btrfs, zfs), it would buffer the corresponding journal writes first.
  • the kernel would flush its buffers (in the appropriate order) during an appropriate i/o idleness period or a deadline, depending on the configured i/o scheduler
  • even if you created, wrote, and deleted the file before such idleness happened, the kernel would eventually update the modified time for the enclosing directory.

tmpfs only touches disk when overall system memory usage is high enough that applications (and whatever processes) use enough memory that it needs to swap to disk. tmpfs blocks get paged out and written to swap like any other application's memory. If you have swap disabled, then your kernel will start killing processes to free memory. But otherwise, nothing touches disk. No journals, no create/access/modify timestamps, no user permissions, no nothing. When you use tmpfs, you're saying "keep these files in memory with everything else, and treat them as forgettable as main memory".

tmpfs was absolutely amazing when it came out, and displaced pretty much every other method for doing "ram disks" in Solaris/Linux (I don't remember where else it was ported).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .