Mount /tmp as tmpfs

[dphn]

I'm interesting in an example for an app, who needs a regular standard /tmp to hold data. I personally prefer the MX configuration. On other systems I've taken this similiar with a fstab config.

Code: Select all

tmpfs /tmp tmpfs nosuid 0 0

[fehlix]

I'm interesting in an example for an app, who needs a regular standard /tmp to hold data. I personally prefer the MX configuration. On other systems I've taken this similiar with a fstab config.

Code: Select all

tmpfs /tmp tmpfs nosuid 0 0

No app should rely on having data kept /tmp, rather in /var/tmp.
In your example at least mode=1777 is missing, as it is needed for /tmp to work properly and option "defaults" might be sufficient to add also.

[MAYBL8]

Ok did all of that.
I now have this:

Code: Select all

dcihon@mx:~/.conky$ cat /proc/mounts | grep tmpfs
udev /dev devtmpfs rw,nosuid,relatime,size=8158164k,nr_inodes=2039541,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1636936k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=6629300k 0 0
tmpfs /tmp tmpfs rw,noatime 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime,size=12k,mode=755 0 0
tmpfs /run/user/115 tmpfs rw,nosuid,nodev,relatime,size=1636932k,mode=700,uid=115,gid=126 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=1636932k,mode=700,uid=1000,gid=1000 0 0

[MAYBL8]

Oops I just saw the edit after I posted.
I will go take out the noatime

[dphn]

I'm interesting in an example for an app, who needs a regular standard /tmp to hold data. I personally prefer the MX configuration. On other systems I've taken this similiar with a fstab config.

Code: Select all

tmpfs /tmp tmpfs nosuid 0 0

No app should rely on having data kept /tmp, rather in /var/tmp.
In your example at least mode=1777 is missing, as it is needed for /tmp to work properly and option "defaults" might be sufficient to add also.

yep. Thx fehlix.

[fehlix]

Ok did all of that.

Some fine tuning can be acchieved if the default 50% of available RAM for /tmp need to be adjusted by explicitely adding a size-option like
size=1G or size=2G, depending on the vailable RAM.
Note: I have corrected and removed "noatime" as this is used for SSD-mounts but not needed for tmpfs-mounts.

[baldyeti]

FWIW my mepis partition indeed had /tmp symlinked to /var/tmp; OTOH neither jessie nor stretch have any tmpfs filesystem mentioned in fstab.

[BitJam]

Note: I have corrected and removed "noatime" as this is used for SSD-mounts but not needed for tmpfs-mounts.

The Linux default of relatime is almost always preferably to the noatime option. Except for some extremely unusually circumstances, the difference in wear and performance will not be measurable when the default relatime is used instead of noatime. There is a lot of bad/incorrect advice about this floating around the internet. It's often given along with the terrible advice of using a non-journaling file system in order to increase performance and decrease wear.

Even back in 2013, Consumer SSDs were benchmarked (to death) and lasted for longer than they were rated. In addition, the endurance of SSDs has increased dramatically since those tests were done. Even with block erase and write-amplification, the tiny bit of extra writing done by relatime is not going to cause significant extra wear. In order to wear out the circa 2013 drives that were tested, the people at TechReport had to write to them continuously, often for over a year. A standard workload over 5 years is a tiny fraction of that; the increase due to journaling and/or relatime is a tiny fraction of that tiny fraction.

[oops]

https://refspecs.linuxfoundation.org/FH ... 05s15.html

5.15. /var/tmp : Temporary files preserved between system reboots
5.15.1. Purpose

The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.

Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.

"... it is recommended that deletions occur at a less frequent interval than /tmp"
... So it is not very explicit and must also be deleted sometimes
(and I still do not know which programs need this functionality)

And:
https://www.tldp.org/LDP/sag/html/var-fs.html

/var/tmp
Temporary files that are large or that need to exist for a longer time than what is allowed for /tmp . (Although the system administrator might not allow very old files in /var/tmp either.)

[fehlix]

Note: I have corrected and removed "noatime" as this is used for SSD-mounts but not needed for tmpfs-mounts.

The Linux default of relatime is almost always preferably to the noatime option. Except for some extremely unusually circumstances, the difference in wear and performance will not be measurable when the default relatime is used instead of noatime. There is a lot of bad/incorrect advice about this floating around the internet. It's often given along with the terrible advice of using a non-journaling file system in order to increase performance and decrease wear.

Even back in 2013, Consumer SSDs were benchmarked (to death) and lasted for longer than they were rated. In addition, the endurance of SSDs has increased dramatically since those tests were done. Even with block erase and write-amplification, the tiny bit of extra writing done by relatime is not going to cause significant extra wear. In order to wear out the circa 2013 drives that were tested, the people at TechReport had to write to them continuously, often for over a year. A standard workload over 5 years is a tiny fraction of that; the increase due to journaling and/or relatime is a tiny fraction of that tiny fraction.

Thanks. Nearly convinced. An actual proof of this message would certainly help, to make a clear and prooven statement,
of our recommended usage of relatime for SSD mounts for all current SSD's - or at least for the one's we are sure about.
Alternatively, we would state this a clear message of MX/antiX recommandations verified/prooven by own expiriences.