Installation Partition Scheme help (/var, /tmp, etc)

Hey all, looking to redo an installation on my video/audio editing, gaming, programming system.
I was looking to be more organized this time around, so I was looking at doing more specific partitions. Particularly, where to put /var, /tmp, and perhaps /usr, what size they should be, and why, is my question.

My system is a 250gb SSD and a 2TB HDD with 16GB of RAM, with GPT and UEFI boot. My plan was to do a system partitioning scheme like this:

sda1 (SSD):

/boot/efi - ~550mb, boot flagged
/ - (rest of drive)

sda2 (HDD):

linux-swap - 4GB
/var - 50GB
/tmp - 100GB
/home - (rest of drive)

I am very unsure about this, particularly the sizes. Here are my grievances with my current plan:

  • From my understanding, /var and /tmp do frequent writes for temporary data, so putting those into the hard drive sounded like a good idea. I am still unsure of what /var and /tmp specifically do, and therefore it is hard for me to gauge what sizes they should really be.
  • I had the similar idea from the above for /home, although, I was looking to hold a place for loading videos fast for video editing. I am unsure how to go about this.
  • Where would /usr fit into this. From what I understand it holds most program data, yes? If so, what program data, and how would having a separate /usr affect my partition sizes?
  • Is putting my /boot/efi in my SSD really necessary? If not, what could I put instead in my SSD?

If it were me, I’d put everything on one partition and install (with the exception of the EFI partiton, of course, which must be there). Then, when everything is done, I would make a small swap file, on the SSD (depending on the amount of RAM my system has, with 16 GB of RAM, I’d make a swap file of 4 GiB) and I would mount a separate HDD (or five) at a location inside /home.

That’s how I’ve always done it.

I see no point in having a super fast SSD and not using it, by putting /var, /tmp, and /usr on a different drive.

3 Likes

What’s your opinion regarding the general size of /var, /tmp, and /usr? Or do you just slap / into the SSD and call it a day?

I see no point in having a super fast SSD and not using it, by putting /var, /tmp, and /usr on a different drive.

The supposed reason I gather is because of the way those directories write into drives, it would put more wear into the drive itself. There is a downside to having these directories in an SSD because of this, and from what I gather, there would be little detriment (if any) to putting it in the HDD. Yeah, I know, I know, modern SSDs don’t have the crazy wear problems like years before.

That’s my point, as well. I don’t think it makes that much of a difference for the longevity of your SSD, but it does make a performance impact.

Yup, that’s pretty much what I do. I make a tiny 260 MiB vfat partition for /boot/efi and everything else is an ext4 partition for /. Then, after install, I mount other drives by adding entries to my /etc/fstab. I mount them in various places inside /home.

Your /usr should definitely be on the SSD, and so should the swap file, as you don’t want an HDD bottleneck (there’s really no point in having an SSD then). I would also leave /tmp there, for the same reason. You could put /var on another drive, after install (just symlink it), but you don’t need a separate partition for it.

1 Like

I am with @Kresimir. My rule of thumb when I do a new installation:

  1. Put it all on the SSD
  2. Only two partitions : / and /home (on UEFI also /boot/efi)
  3. no swap partition. I use a swapfile on my laptop and zram-generator on my desktop

/tmp is put on a tmpfs by default. That makes sense and because /tmp should be cleaned every boot it does not make sense to make it big like 100 GB.

/home should be on the SSD if you want to get the most performance out of it. There are frequent reads and writes to ~/.config, ~/.local and such. It makes sense to have them on the fastest drive.

2 Likes

What would you do with the HDD at that point? Is there a way to make it a permanent mount somewhere? What would be a valid name for it?

I don’t even make a separate partition for /home. I see no point in doing so, except maybe if you reinstall often and want to keep that partition intact… But for the most part, it is just dividing useful storage space into two and increasing the chance of running out of it.

1 Like

Yes. You mount by editing your /etc/fstab. You can mount it to any directory. I typically do it inside my /home directory. So one of my HDDs would be something like /home/kresimir/Storage, and another would be /home/kresimir/Videos and maybe /home/kresimir/Downloads

And you can symlink your directories, if you want an organised hierarchy. So you can keep your videos on your “Storage” HDD which is mounted at /home/username/Storage and have a directory in it named “Videos” which you symlink to /home/username/Videos. You can do organise it like this however you like.

1 Like

Dividing partitions are extremely helpful when things go wrong. Example being that my OS has been donked and I wish to rescue my personal files (which has happened before). To my knowledge, there is no real way to do that without /home being on its own partition.

I have a very similar setup on one of my PCs. I use the HDD for /data. And that holds all pictures (photos), videos, music, etc. I also have a /data/tmp directory where I put temporary stuff like work in progress.

A nice thing about Linux filesystems are links. You could relocate the biggest directories in $HOME like ~/downloads or ~/documents to your HDD, e.g. /data/Nocturn_Adrift/Documents, and link this to your $HOME. And if you dont like links you can use “mount --bind”. I use links and binds.

But then dont forget to include /data/Nocturn_Adrift in your backups.

4 Likes

Pretty based if I say so myself. Thanks to the both of you, @mbod and @Kresimir, this sounds like the ideal solution for me as of right now.

At best, it is convenient if you reinstall your system often. But when things go wrong, I try to fix them instead of just reinstalling.

But even if you must reinstall (which in 99% cases you don’t) you can still access an unbootable system from a live ISO image, and copy your files before formatting the drive.

And if things go wrong in the sense of losing data (like a hardware failure), having multiple small partitions won’t help you much in such a case.

Besides, you should have a backup (actually, multiple backups) on external drives for all important files, because hardware failure happens with all storage, and it’s not a matter of if, but when.

1 Like

I’ve used symbolic links before, but never heard of binds. I will take a look, but in short, what is the difference between the two?

I do the same thing, but I don’t put /data in / but in my user’s home directory. I find it more logical keep to the user space contained in home. So for me it would be /home/kresimir/data.

It’s a personal preference, really. With symlinks you don’t think about where everything is physically stored.

Just occurred to me that this would somewhat solve the dotfile problem in the /home directory. I still can’t wrap my mind around why so many GNU-Linux programs insist on storing hidden files in /home. Annoying to no end.

Main difference: bind mount dont look ugly when you do “ls -l” :rofl:
Just kidding.

For your daily work they are both pretty equal. It is hard to tell for me which is better or which to prefer. If you google it you can find tons of opinions about your question.

1 Like

That does not work with a multi user setup. I have family members who need access to /data too.

EDIT:
Therefore I have /data/user1, /data/user2, etc. subdirectories.

2 Likes

Indeed, if multiple people use the computer with different accounts, then it becomes a permission nightmare if you have one user accessing another user’s home. /data makes total sense then.

But since I’m the only person who uses my computers, it makes sense for me to keep it all inside my home directory.

If, however, I change my mind, relocating the mountpoint is just a matter of editing one line in /etc/fstab and fixing a few symlinks. No copying of data needed.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.