# Making /var/temp/portage and /tmp coexist in ram?

## IRQsRFun

It is my understanding that if /tmp is in a tmpfs, performance can be improved.  I have sufficient ram for this if I can dynamically disable or readjust the the 6G currently allocated for /var/tmp/portage.  

As far as /tmp being in a tempfs is concerned, I am looking to be able to do an emerge from the command prompt and still use the computer as a desktop without rebooting.

I am considering reconfiguring portage to use something like /tmp/myGentoo in place of /var/tmp/portage for emerging, but I am not yet 100% happy with this.  

Does anyone have suggestions or comments to get around this limitation?  Am I misunderstanding what is happening when assign a path to tempfs?

Any help or comments would be appreciated.

----------

## Hu

There is no need to change PORTAGE_TMPDIR.  You can mount a tmpfs anywhere.  You can have multiple tmpfs, each with its own maximum size.  A tmpfs uses very little memory when it is empty, so you are primarily bound by the number and size of files stored in it.  Unlike some earlier RAM disks, a tmpfs can be swapped.  This can be useful in some cases if you find that you started out using a tmpfs and cannot easily move to another filesystem.

System interactivity can be affected by excessive use of memory for a tmpfs, especially if the tmpfs causes the system to begin paging.  However, if you have 6G of RAM, you should have acceptable interactivity for small to medium size packages.  Building OpenOffice or a massive KDE/GNOME update might be stressful.

----------

## IRQsRFun

Hu,

Thank you for reminding me that amount of memory used by tempfs can be small, even with a relatively large file system.

I am open to suggestions on how to determine how much swapping is going on.  I suspect that this may be something I would want to be a able to monitor.

----------

## Hu

You can use free to see how much swap is used, but that does not directly distinguish between swap that was used because you overloaded a tmpfs and swap that was used because you ran an application which hogged memory.  The default size for a tmpfs is half of physical RAM.  For a 6G machine, this should allow you to build any package that is worth building in a tmpfs.  Packages which do not fit there are probably going to be limited by other factors anyway, and should be built on a disk-backed filesystem.

----------

## jbouzan

I have both /tmp and portage on shmfs with only 2gb of ram here, and it almost never pages. You just need to make portage delete failed builds to clear space in the tmpfs. 

```
FEATURES="fail-clean"

PORT_LOGDIR="/mnt/portdir/logs"

PORTAGE_TMPDIR="/mnt/portdir"
```

in make.conf with 

```
#Temp filesystems

shm                     /mnt/tmp        tmpfs           size=1g                 0 0

shm                     /mnt/portdir    tmpfs           size=1536m              0 0

shm                     /tmp            tmpfs           size=1g                 0 0

shm                     /var/tmp        tmpfs           size=1g                 0 0
```

in fstab. Even a /var/tmp/portage as large as 1.5gb is only necessary for gcc, kdelibs, and netbeans. Anything else I've compiled never approached 1 gb (although I use libreoffice-bin instead of compiling it).

Just to show, free -m about halfway through mesa update right now.

```
$ genlop -tc

 Currently merging 1 out of 2

 * media-libs/mesa-7.10.1                                                                                                                                        

                                                                                                                                                                 

       current merge time: 2 minutes and 44 seconds.                                                                                                             

       ETA: 2 minutes and 18 seconds.

$ free -m

             total       used       free     shared    buffers     cached

Mem:          1998       1920         77          0        121        558

-/+ buffers/cache:       1240        757

Swap:         4102          0       4102

$ df -h

Filesystem            Size  Used Avail Use% Mounted on

shm                   1.5G   85M  1.5G   6% /mnt/portdir

shm                   1.0G   12K  1.0G   1% /tmp

shm                   1.0G  5.5M 1019M   1% /var/tmp

```

----------

## Hu

Space usage depends in part on CFLAGS.  If you set flags that bloat the generated files, such as -ggdb, you will need considerably more space.  You would usually do this only when preparing to debug a package, though.

----------

## s_bernstein

I never quiet figure out why there are 2 tmp directories - /tmp and /var/tmp. So what I did was I linked my /var/tmp to /tmp,  which is a tmpfs. Now I only need on tmpfs, which, by default, will use up to half of my ram. This works fine even on a machine with only 2 GB ram (except for compiling netbeans, which will need more than 1GB space for sources alone.).

Also this solution is similar to mounting multiple tmpfs, there is one big difference, which make this solution better working for small amounts of ram. Using 2 tmpfs for /tmp and /var/tmp with default settings could use up all your memory - in a worst case scenario - whereas using just one tmpfs it will be restricted to half of your ram. Also there is better control of the overall ram usage of tmpfs (say: max. 3/4 of ram, in my case 1536m).

----------

## cwr

/tmp goes away (usually) on every boot,  but /var/tmp is preserved, which is why portage

stores its builds there.

If you want to monitor swap (as well as other things) conky isn't a bad way to go.

Will

----------

## s_bernstein

 *cwr wrote:*   

> /tmp goes away (usually) on every boot,  but /var/tmp is preserved, which is why portage
> 
> stores its builds there.
> 
> 

 

Ah.. a shed of light. But portage only preserves unsuccessful builds. So why should I care for them after a reboot? They only clutter my disk with unwanted data.

----------

## depontius

 *s_bernstein wrote:*   

> Ah.. a shed of light. But portage only preserves unsuccessful builds. So why should I care for them after a reboot? They only clutter my disk with unwanted data.

 

Because on the current boot you don't have time to diagnose the failed emerge.  So you get to it on the next boot.

Probably rather unlikely, but other than that I can't think of a good reason, either.

----------

## s_bernstein

 *depontius wrote:*   

> 
> 
> Because on the current boot you don't have time to diagnose the failed emerge.  So you get to it on the next boot.
> 
> Probably rather unlikely, but other than that I can't think of a good reason, either.

 

OK, I just thought I've missed something important.   :Smile: 

----------

## depontius

Now that I think of it, I've also manually patched some packages.  Instead of "emerge" I use "ebuild unpack", edit the source code, then "ebuild install" and "ebuild qmerge".  I have a copy of coreutils in /var/tmp/portage right now which I bastardized in order to pass platform detection on some binary-only software.  The obvious solution is that I really ought to tar the tree and save it somewhere eise.

----------

## Suicidal

 *cwr wrote:*   

> /tmp goes away (usually) on every boot,  but /var/tmp is preserved, which is why portage
> 
> stores its builds there.
> 
> If you want to monitor swap (as well as other things) conky isn't a bad way to go.
> ...

 

My /var/tmp goes away every reboot :- )

Nothing in there that needs to be preserved.

----------

## Hu

 *depontius wrote:*   

> The obvious solution is that I really ought to tar the tree and save it somewhere eise.

 You could instead set up an overlay that automatically patches sys-apps/coreutils with the changes that you needed to satisfy the closed software.

----------

## cwr

 *depontius wrote:*   

> Now that I think of it, I've also manually patched some packages.  Instead of "emerge" I use "ebuild unpack", edit the source code, then "ebuild install" and "ebuild qmerge".  I have a copy of coreutils in /var/tmp/portage right now which I bastardized in order to pass platform detection on some binary-only software.  The obvious solution is that I really ought to tar the tree and save it somewhere eise.

 

Once you've got a patch, it's easier just to put the package into a local overlay - that way it's fixed forever.  You can either mask

later versions, or just re-install them in the local overlay.

Will

----------

## Suicidal

 *cwr wrote:*   

>  *depontius wrote:*   Now that I think of it, I've also manually patched some packages.  Instead of "emerge" I use "ebuild unpack", edit the source code, then "ebuild install" and "ebuild qmerge".  I have a copy of coreutils in /var/tmp/portage right now which I bastardized in order to pass platform detection on some binary-only software.  The obvious solution is that I really ought to tar the tree and save it somewhere eise. 
> 
> Once you've got a patch, it's easier just to put the package into a local overlay - that way it's fixed forever.  You can either mask
> 
> later versions, or just re-install them in the local overlay.
> ...

 

Or you can try the patch on newer versions, editing the ebuild and throwing in your own epatch line would seem less of a PITA to me.

----------

## depontius

Thanks for all of the suggestions, but what I'm doing is really SOOOOO ugly I haven't wanted to "refine" it enough to turn it into a patch or ebuild.

I'm telling "uname -r" to append ".el5" to the real answer.  Some of the binary-only software is for VLSI CAD, and there's a short-sighted platform test that rather than checking real requirements, looks for RHEL5.  I believe that part of the stuff is coded in-house, but then we're getting into shop politics, and that's a lost one before I even start, so I just work around it.  But it's UGLY!

----------

## Suicidal

Why just not add .el5 to localversion in kernel config?

----------

