Support for MX and antiX Linux distros
http://www.forum.mxlinux.org/
Code: Select all
tmpfs /tmp tmpfs nosuid 0 0No app should rely on having data kept /tmp, rather in /var/tmp.dphn wrote: Sun Dec 23, 2018 10:40 am 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
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
yep. Thx fehlix.fehlix wrote: Sun Dec 23, 2018 11:01 amNo app should rely on having data kept /tmp, rather in /var/tmp.dphn wrote: Sun Dec 23, 2018 10:40 am 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
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.
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
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.fehlix wrote: Sun Dec 23, 2018 11:18 amNote: I have corrected and removed "noatime" as this is used for SSD-mounts but not needed for tmpfs-mounts.
"... it is recommended that deletions occur at a less frequent interval than /tmp"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.
/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.)
Thanks. Nearly convinced. An actual proof of this message would certainly help, to make a clear and prooven statement,BitJam wrote: Sun Dec 23, 2018 2:24 pmThe 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.fehlix wrote: Sun Dec 23, 2018 11:18 amNote: I have corrected and removed "noatime" as this is used for SSD-mounts but not needed for tmpfs-mounts.
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.
