Practical questions for having /tmp and /var on same partition
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Practical questions for having /tmp and /var on same partition
Hi.
I just installed MX Linux onto a computer, and tough the installer does provide an option to have separate / /root /home and swap partitions, it does not natively offer the user to specify partitions to put /var and /temp.
Therefore, I have set aside 25BG free space for this purpose. I also want to put /var and /tmp on same one partition.
var and /tmp can be filled up by user programs or daemons. Therefore it can be safe to have these in separate partitions that would prevent /, the root partition, to be 100% full, and would hit your system badly. To avoid having two distinct partitions for these, it is not uncommon to see /tmp being a symlink to /var/tmp.
The first practical question - what steps are necessary to do this? According to last post in this askubuntu forum thread:
Quote:
if you provide an existing directory instead of the link name, ln will create a link inside that directory
You will probably have to do these steps from a rescue DVD. If you try them on a live system the system will probably crash part way through the rearrangement.
Format the new partition.
Move the contents of /var to the new partition leaving /var as an empty directory on /.
change /etc/fstab to mount the new partition on /var
delete /tmp on / and recreate /tmp on / as a symbolic link to /var/tmp
The only possible problem I see with what you are attempting is if the boot process uses /tmp before /var is mounted through /etc/fstab. I don't think that is what actually happens so I think it should work.
--------------------------
Steve Stites
Last edited by jailbait; 01-13-2021 at 06:43 PM.
Reason: format
The practice of putting /var and /tmp on separate partitions dates back through the mists of time when hard drives were still relatively new and extremely small. With today's hard drives, it should not be necessary.
I common allocate 25-30GB for my root partition, which contains everything except /home, and have never experienced any issues related the /var and /tmp. (Before I started doing that, I would have just one root partition containing everything, and also never encountered any issues.)
The only possible problem I see with what you are attempting is if the boot process uses /tmp before /var is mounted through /etc/fstab. I don't think that is what actually happens so I think it should work.
Good point!
systemd places files in /tmp
If these are overmounted, it might misbehave.
EDIT
I think it uses the /tmp later, not before mounting, so it is likely not a real problem.
Last edited by MadeInGermany; 01-14-2021 at 03:19 AM.
I think it uses the /tmp later, not before mounting, so it is likely not a real problem.
The new idea is to use /run.
Putting /tmp and /var on their own partition(s) is only useful for servers. There a lot of users may create a lot of data on /tmp, while databases typically make use of /var to keep track of things.
FWIW, /tmp is a tmpfs (aka RAM disk) on my system.
Major distros seem to disagree about what exactly /tmp should be, but I think that's the right way.
There's more:
FWIW, /tmp is a tmpfs (aka RAM disk) on my system.
tmpfs, AKA “a symlink to /dev/shm” or just any kind of ramdisk for temporary data should be a natural choice. I do not know if my use of the temp-directory qualifies me as a security-freak. But knowing that wiping RAM is quite different from wiping a hard-disk has its charms. – Knowing that not doing anything at all is enough for a RAM-disk, too.
Last edited by Michael Uplawski; 01-16-2021 at 12:25 AM.
I moved the contents of the old /var and /tmp to the new location.
I've made a symlink to the new locations (/sda/mx_var/ and /sda/mx_tmp/ ) (not sure if I should have used "/dev" before).
However the editing of /etc/fstab file I don't know how to proceed further from this. From what I read, fstab can only deal with volumes and not folders within.
As it sits now, the system are not able to boot (see screenshot of the boot error messages)
attempt 1 : the symlinks does not include "/dev" (probably wrong anyway)
attempt 2 : the symlinks does include "/dev" --> "dev/sda5/mx_var/"
So far, the /etc/fstab file are not changed in any way.
I wouldn't do it with symlinks. I'd just have empty /var and /tmp directories on the root partition and put them into fstab as mountpoints. In most modern distros /tmp is empty anyway and a tmpfs (ramdisk) is mounted there.
re your query about unnamed symlinks:
Quote:
if you provide an existing directory instead of the link name, ln will create a link inside that directory
In creating a symbolic link, the target always comes first, then the link name. If no link name is given, the name will be the same as the target file. Obviously this will not work if you simply type
Code:
ln -s target .
because you can't have two files of the same name in the same directory. However:
Code:
ln -s target /other_directory
will work. It will create a link at /other_directory/target.
Your images show a successful boot though some daemons have failed. The acpi errors are not serious. It might be worth logging in and exploring the system to find out what the /var and /tmp directories actually contain.
However, If I stuck to the plan and have to use fstab, the issue is that the first column of fstab file cannot point to a folder within any partition/volume.
The whole /var in tmpfs is not a good idea, many setups use data stored there, must survive reboot. First column can have directories, use bind mount for those.
However, If I stuck to the plan and have to use fstab, the issue is that the first column of fstab file cannot point to a folder within any partition/volume.
So don't use a folder. Make a partition of a suitable size for your /var contents and use that, mounting it on the empty /var directory. As Emerson pointed out, there are important databases stored here so you want it to be permanent.
And set up /tmp as a tmpfs if it isn't that way already.
Ok, so I ended up no being able to restore the MX desktop, despite attempting to copy the contents of /var back again (created the /tmp and /var folder and copied back it's content in order to try to fix the MX desktop issue).
But - no problem, it's a test setup for this purpose anyway.
So for now - lessons learned as following:
tempfs are probably the way to go regarding /tmp
If /var is removed manually, it may be very hard or impossible to make it work again (for a beginner like me at least). Maybe a workaround here would be to just rename the /var folder and when renamed back it's al good - or maybe the system does something when it doesn't find/accept /var that screw up the desktop regardless to wether I restore it back or not.
The original goal of making /tmp and /var physically located in same partition seems impossible at this moment.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.