[gentoo-amd64] Re: Unexpected side effect of GCC 4

[Duncan]

Peter Humphrey <prh@××××××××××.uk> posted
200611061144.01773.prh@××××××××××.uk, excerpted below, on  Mon, 06 Nov
2006 11:44:01 +0000:

> On Monday 06 November 2006 08:41, Duncan wrote:
>
>> Peter Humphrey <prh@××××××××××.uk> posted
>> > Perhaps I ought to look into putting /tmp and /var/tmp onto tmpfs.
>>
>> Do so.  It makes a /big/ difference!
>
> My reading so far suggests that I include these two lines in /etc/fstab:
>
> tmpfs  /tmp     tmpfs  nodev,nosuid,noexec  0 0
> tmpfs  /var/tmp tmpfs  nodev,nosuid,noexec  0 0
>
> Is that all I have to do? I assume I don't need to specify tmpfs sizes; I
> have 4 GB RAM of which 0.5 GB is unavailable (owing to a motherboard
> problem that prompted the system builder to refund some of my money -
> small consolation).

I believe I remember your posts talking about that, back when I still had
only a gig of RAM.  Now that I have more than 3.5 gig of memory myself, I
know a bit more about the memory hole and all that.  If you have bios
entries for configuring it and just couldn't get it to work before, maybe
now that I know a bit more about the issue, we could try to work thru it. 
Of course, if you don't have the BIOS entries, it's just not going to
happen...

You don't /need/ to specify tmpfs size, but it might be worthwhile to do
so.  You don't want a runaway file in /tmp to take up all your memory and
swap.  Be aware that if you mount as tmpfs any location normally
having global write permissions (the usual 1777 of /tmp for instance), you
are letting any account have access to that memory.  If you are the only
human user of the machine, that's probably fine, but if not, you may want
to ensure you are running quotas on it or something, and have them set
appropriately.

If you are just concerned about portage, you can of course point
$PORTAGE_TMPDIR at a location other than the default, and set that
location user portage group portage, 740 permissions or similar, so only
portage (and root of course) can write to it.  It's still possible that
anyone in group portage could abuse it, but not simple users not in group
portage. then.

Here, as I'm the only human user, I don't have to be quite so strict on
security.  To keep things simple, /var/tmp is a symlink to /tmp, so I don't
have to worry about a tmpfs for both dirs.  You'll want to set the
following in make.conf:

PKG_TMPDIR
PORTAGE_TMPDIR
PORTAGE_TMPFS

Note that setting the latter to a small, say 50 meg, tmpfs, is useful
even if you aren't setting PORTAGE_TMPDIR on tmpfs.  It's used for
quick/small stuff like lockfiles and the like.  The portage docs suggest
setting it to /dev/shm, an LSB standard location for such things.  I have
a separate (max 50 meg as I said) tmpfs mounted at /dev/shm and followed
the recommendation to point PORTAGE_TMPFS at it.

Of course, you'll only need PKG_TMPDIR if you have FEATURES=buildpkg set
or otherwise deal with binary packages.

I have /tmp (which is where both the package and portage TMPDIRs point) set
size=5g here, with 8 gig memory. With 3.5 gig of memory, you may wish to
set something a bit smaller, say 3 gig. That should be fine for most
emerges and will keep it from going too much into swap if something should
start hogging your tmpfs.  Of course, you'll have to make it a bit bigger
for merging say OOo (not the bin-version), as it is said to require 5 gigs
of space (I don't use it so wouldn't personally know), but you could use
remount for special cases like that, keeping it to 3 gig or so normally.

> Probably I should put a script into /etc/conf.d/start.local to create a
> symlink from /var/tmp/ccache back to a real cache directory on disk, as
> it seems daft to install a compiler cache and then flush it at every
> reboot - at present mine has 1.5 GB of data. /tmp has 750 MB of stuff
> and is a separate disk partition at present, mounted on whichever system
> I boot.

Don't worry about that symlink.  Set CCACHE_DIR in make.conf directly,
instead. Here, I have it pointed at a subdir on my fast raid-0/striped
array.  That works quite well.  Since all the stuff portage normally uses
(gcc, grep, sed, libraries commonly linked, etc) read into the regular
kernel filesystem cache memory during the first emerge, and with all the
work being done on tmpfs, there's little i/o but the ccache write updates
going on during all but the qmerge phase of subsequent emerges.  The disk
spends most of its time idle, and you can watch the disk activity light
and tell when the kernel's cache flush writes kick in, as it blinks red a
couple times every few seconds.  That's it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list