Which to mount as tmpfs, /tmp or /var/tmp/portage?

Splooshie123 · n00b Joined: 16 Apr 2012 Posts: 27

I want to mount the /tmp folder in ram but I don't know whether it would not be better to do that with /var/tmp/portage instead.

Which folder generally uses more space? If the combined size is small enough, I might even decide to have both as tmpfs.

jormartr · Apprentice Joined: 02 Jan 2008 Posts: 174

/tmp is a general temp folder, while /var/tmp/portage is used by portage when compiling.

The use on the first depends on the applications that you use and might use /tmp.

The second one will need quite space for portage to run.

I personally use tmpfs on /tmp, and do a bind mount of /tmp/var_tmp_portage on /var/tmp

Splooshie123 · n00b Joined: 16 Apr 2012 Posts: 27

I'm mostly browsing the Web with the computer. Firefox seems to keep its own cache in the home folder so /tmp is less than a megabyte. So /tmp is safe enough.

/var/tmp/portage I'll just have to try experimenting...

yellowhat · Guru Joined: 10 Sep 2008 Posts: 528

I am using from a while /tmp on tmpfs.
I am using chromium cache and portage compiling for almost all the emerging (chromium and libreoffice on hard drive) on it.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

I make them both 4GB and have extra swap space.

Splooshie123 · n00b Joined: 16 Apr 2012 Posts: 27

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

In my experience the /tmp project has marginal value, but the /var/tmp/portage one makes a huge difference when upgrading your packages.

Using tmpfs for where your web browser stores things is irrelevant. No matter how slow a hard disk is, it's gonna be faster than your internet connection.

I've used tmpfs quite a bit, and here's my strategy:

Install normally.
Use your machine, and figure out what operations you spend time waiting for the computer to finish, and which use disk heavily.
For the worst offender (portage for example) you find out where it writes its temp storage to.
Time an operation (compiling Libre for example) as a reference. For fairness, install it untimed first, the unmerge it, then time the re-merge. This way you don't have inaccurate results for all the additional dependencies that come along for the ride.
Mount that are as tmpfs, and make it plenty big because chances are that RAM will never be used or swapped anyway.
Try the app again and measure the improvement in performance.

FWIW I only found a few places that made sense for me, and /tmp was not one of them.

I submit that before you play with this, you get your system to a state where you never use more than half your RAM for actual running of the computer. I have 12g, and I have 4 disks each of which has a 12g swap partition. I use them all in theory, but AFAICT no bytes have ever been written to any of them except when my system hibernates or sleeps.

IMO the easiest, best way you can improve your system's speed is to increase RAM to a stupidly large amount. RAM is cheaper than it has ever been, and it doesn't take a lot to get good performance. Linux uses your extra RAM as a disk cache, so if you leave your system running most of the time it will eventually fill your RAM up with disk cache. Usually by the end of a week of uptime, I get about 10g used total, and by the end of a month it's 11g or so. Once everything is cached, everything starts up really fast.

The absolutely worst thing you can do is to have so little RAM that you actually use SWAP for its original purpose. SWAP algorithms are really good at deciding what needs to go out, but an app that things it's storing on RAM but instead is waiting for a disk to seek-write-flush-etc is going to really kill your performance.