Portage TMPDIR on tmpfs

When emerging packages it is possible to build them in tmpfs (RAM) space instead of having build files pushed and pulled to Hard Disk Drive (HDD) or Solid State Drive (SSD) space. Building in tmpfs both speeds up emerge times and reduces HDD/SSD wearing. For system's containing SSDs, it is generally a good idea to have Portage compile using tmpfs (RAM) instead burning up precious SSD write cycles (especially on something like compiling software).

fstab Configuration
Mount Portage's  to tmpfs by adding the following to the system's  config file:

Adjust the  parameter  to the desired amount of RAM. Systems with large amounts of RAM can increase the number quite significantly.

After has been modified, mount Portage's TMPDIR to RAM by running the   command followed by the directory location outline in :

Considering tmpfs' Size
The system's tmpfs space should be large enough to handle the largest packages to be compiled on the system. If the tmpfs space were to ever become completely full then the emerge will fail. Most packages do not need more than 1 GB of tmpfs space their compiles, but there are few very large packages. If you have a lot of RAM, setting be careful to include enough tmpfs space when installing the following packages:


 * 10GBs or so.


 * More than 2GBs.


 * More than 4 GiB.

Per-Package Choices at Compile Time
Portage can be configured to build large packages outside of the tmpfs space on a per-package basis.

Create a file to tell Portage where to place the temporary files directory:

Create a separate temporary file directory outside of the tmpfs mount location:

Create a special Portage file called !/etc/portage/package.env in and list all the packages that are too large to be compiled using tmpfs:

No space left on device problem
If you encounter a not-enough space error or anything similar, there are basically two things to do:

1) You should check  for stale directories from packages that previously failed to compile.  You should delete them besides the one that belongs to the current package so you can still try to resume it later.

2) You can resize your tmpfs.

Resizing tmpfs
To resize your current tmpfs instance in, you can run

Where N is in the form of bytes. It can also be suffixed with,  , or   to respectively have the form of kilobytes, megabytes or gigabytes. It can also be suffixed with  to limit the tmpfs instance to the percentage of current physical RAM, in which the default is 50% of it.

Note that it would not persist into the next boot. You can make it permanent by modifying the parameters in, but that would not really be necessary as having a large tmpfs would only be important during compilation of large packages.

It is recommended to leave-out at least 1G space for the system to prevent out-of-memory problems. Using swap-disks for some heavy compile-time and link-time instances which are unexpected may also be helpful. Now even if you use swap-disks, reads and writes to it would only be minimal compared to having a physical filesystem behind.

Here's a note about the size parameter in Linux kernel's documentation which can be found in : size: The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.

Besides the obvious danger of allocating too much memory for tmpfs that it could choke the system, it generally should be be safe to enlarge the tmpfs during an emerge as technically what it only does is increase the size limit of it.

For example, if you have 12 GB of RAM and 3 disks with 2 GB of swap on every of them working in parallel, then it would be pretty safe to choose size limit equal to 16G. 16 GB size is usually enough to compile libreoffice and chromium in parallel (usual emerge -1uDN @world) while reading Internet in your browser.

It's not often that you'll ever have to do it and  would tell you that tmpfs is too small however there are instances that the package's ebuild would be not so accurate at estimating the amount of disk space necessary for building the package. Newer packages may end up allocating more space, whereas using lesser USE flags would make it allocate less.

Anyway your solution for this is to either enlarge tmpfs, or add the exception to, and then run   again.

Save an emerge and Resume Later
Example: emerging webkit-gtk can take a long time. I want to reboot into another OS and resume this ebuild later.


 * Optional: I use app-portage/genlop to inspect my current emerge. I like using it to remind me of the ebuild version number or hopefully to get an ETA.


 * I do  out of the current emerge


 * Since I am rebooting, I'll have to use  or   to save   while preserving permissions. Otherwise the tmpfs contents will be lost; You may want to inspect the memory size of   by using  :


 * Reboot, do other stuff, come back


 * Restore


 * Resume the ebuild with

If you're using other repository sources besides  like layman overlays, make sure that you're using the correct repository directory of the ebuild as one package can also belong to other repositories and be chosen to be installed over the one in. You can get the repository name of the current package by reading the last action entry in  or reading the build.log file in the package's build directory with a command like.

Do not use the .ebuild file found in  as it seems to be only a reference. Perhaps there's a way to use it, but one would have to thoroughly understand how  and   work.

Happy hacking :)