Support for MX and antiX Linux distros
http://www.forum.mxlinux.org/
couldn't find anything fresh on this over recent forum posts.Code: Select all
tmpfs /tmp tmpfs noatime,nosuid 0 0Yes , and to check:dphn wrote: Sat Dec 22, 2018 7:28 am You don't need it on MX. /tmp linked to /var/tmp and this loads to RAM. Good configuration on MX.
Code: Select all
cat /proc/mounts | grep /tmp
#or
cat /proc/mounts | grep tmpfsCode: 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
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
This means that neither /tmp nor ( symlinked to) /var/tmp is mounted into shared memory RAM (aka tmpfs)dcihon wrote: Sat Dec 22, 2018 5:53 pm Mine shows this but I don't know what any of it means:
Is my SSD ok with this?
Code: Select all
tmpfs /tmp tmpfs defaults,mode=1777 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 /var/tmp tmpfs rw,relatime 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
nice , when you open /tmp in Thunar you see free space is related to your available ram.dcihon wrote: Sat Dec 22, 2018 6:24 pm Ok now it shows 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 /var/tmp tmpfs rw,relatime 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
This configuration does not follow the Linux Filesystem Hierarchy Standard. It is okay for /tmp to be tmpfs because there is no guarantee that files under /tmp will survive a reboot. But the whole point of having a separate /var/tmp is so that files put there can survive a reboot.dphn wrote: Sat Dec 22, 2018 7:28 am You don't need it on MX. /tmp linked to /var/tmp and this loads to RAM. Good configuration on MX.
/var/tmp : Temporary files preserved between system reboots
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.
Thanks, for pointing that out.BitJam wrote: Sun Dec 23, 2018 1:49 am 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.
The question remains, how can we follow the Linux Filesystem Hierarchy Standard, which states clearly:BitJam wrote: Sun Dec 23, 2018 1:49 am It is okay for /tmp to be tmpfs because there is no guarantee that files under /tmp will survive a reboot.
As within the installed system we do have currently /tmp symlinked => /var/tmp and by this we do not follow the standard,Chapter: 3.18. /tmp : Temporary files wrote:Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
Code: Select all
#uncomment to have /tmp as temporary filesystem that resides in memory
#tmpfs /tmp tmpfs defaults,mode=1777 0 0Yes, the point is, as soon as you install a app/programm, which is programmedoops wrote: Sun Dec 23, 2018 9:04 am @fehlix ...The question is especially: is this standard relevant?
For which features /var/tmp is very important to keep?
Otherwise there is no relevance to changing current behavior (IMHO).
Good question .. you might find out (or not) when something is not behaving properly, and you start to debugoops wrote: Sun Dec 23, 2018 9:18 am @fehlix
Yes but exhaustively, for which programs (they must be very very rare?)
Code: Select all
if (exitStatus == QProcess::NormalExit) {
updateStatus(tr("Fixing configuration"), 99);
chmod("/mnt/antiX/var/tmp",01777);
shell.run("cd /mnt/antiX && ln -s var/tmp tmp");
May I interpret your comment, as support of my proposal to keep /tmp not symlinked to /var/tmp in MX Linux, which I hope is the caseanticapitalista wrote: Sun Dec 23, 2018 9:35 am Running live does not symlink tmp to /var/tmp.
Only on installation does it do so.
The gui installer has these lines.
This must have been a decision by MEPIS.Code: Select all
if (exitStatus == QProcess::NormalExit) { updateStatus(tr("Fixing configuration"), 99); chmod("/mnt/antiX/var/tmp",01777); shell.run("cd /mnt/antiX && ln -s var/tmp tmp");
antiX cli-installer also does not symlink tmp to var/tmp
From MX-19 onwards, ok if the other devs have no objections.fehlix wrote: Sun Dec 23, 2018 9:47 amMay I interpret your comment, as support of my proposal to keep /tmp not symlinked to /var/tmp in MX Linux, which I hope is the caseanticapitalista wrote: Sun Dec 23, 2018 9:35 am Running live does not symlink tmp to /var/tmp.
Only on installation does it do so.
The gui installer has these lines.
This must have been a decision by MEPIS.Code: Select all
if (exitStatus == QProcess::NormalExit) { updateStatus(tr("Fixing configuration"), 99); chmod("/mnt/antiX/var/tmp",01777); shell.run("cd /mnt/antiX && ln -s var/tmp tmp");
antiX cli-installer also does not symlink tmp to var/tmp
Sorry about this
Code: Select all
tmpfs /tmp tmpfs defaults,mode=1777 0 0Code: 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.
This last sentence is I'm all about. And I'm so thankful you summarized all your clear thoughts in such consize manner. This is more than enough to have a well educated and well proven statement from with MX/antiX community and development team to go further.BitJam wrote: Mon Dec 24, 2018 3:43 pm .. I'm not sure how much more proof you need.
.. But those old rumors are hard to kill.