public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: Unexpected side effect of GCC 4
Date: Wed, 8 Nov 2006 15:17:38 +0000 (UTC)	[thread overview]
Message-ID: <eissei$dvt$1@sea.gmane.org> (raw)
In-Reply-To: 200611081119.07931.prh@gotadsl.co.uk

Peter Humphrey <prh@gotadsl.co.uk> posted
200611081119.07931.prh@gotadsl.co.uk, excerpted below, on  Wed, 08 Nov
2006 11:19:07 +0000:

> I decided on an even simpler approach. As I don't really want all the other 
> stuff in /var/tmp to evaporate every time I shut down, I put /tmp on 
> tmpfs, with this entry in /etc/fstab:

> 	tmpfs	/tmp		tmpfs	nodev,nosuid,size=85%		0 0

Hmm...  I wasn't aware size could be set as a percentage of memory.  man
mount says size is in bytes, and offers the suffixes k, m and g, with no
mention of the % suffix, tho it does say the default is half of memory.

Does the 85% actually work as implied?  If so, I just learned something
new. =8^)
 
> Then I added these entries to /etc/make.conf:
> 	BUILD_PREFIX="/tmp/portage/build"	# not sure I need this

I don't think you do.  I don't have that var set here.

> 	CCACHE_DIR="/var/tmp/ccache" # to make sure it doesn't go looking in/tmp
>       PORTAGE_TMPDIR="/tmp"
> 
>> Note that setting [PORTAGE_TMPFS] 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.
> 
> Where did you find this recommendation? I can't find any reference to
> it.

PORTAGE_TMPFS is a fairly new setting that may not have made it to stable
portage yet. It doesn't appear to have made it into the make.conf manpage
yet, but from make.conf.example:

# PORTAGE_TMPFS is a location where portage may create temporary files.
#     If specified, portage will use this directory whenever possible
#     for all rapid operations such as lockfiles and transient data.
#     It is _highly_ recommended that this be a tmpfs or ramdisk. Do not
#     set this to anything that does not give a significant performance
#     enhancement and proper FS compliance for locks and read/write.
#     /dev/shm is a glibc mandated tmpfs, and should be a reasonable
#     setting for all linux kernel+glibc based systems.
#PORTAGE_TMPFS="/dev/shm"

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

Hmm... I don't see any documentation on this.  A google search on
PKG_TMPDIR turns up mostly BSD references (here you can see portage's BSD
heritage, Daniel Robbins found the concept there and liked it so created
portage for Gentoo when he started it).  However, adding the terms portage
or gentoo to the search helps.  There are a bit less than a hundred hits
in each of those two cases.  They are interesting but I don't see anything
authoritative.

I must have picked it up elsewhere, probably from either the gentoo-dev
or gentoo-portage lists, or from gentoo-user, which I followed for a few
months as a newbie.

Anyway, PKG_TMPDIR/binpkgs is used temporarily when merging binary
packages.  Thus, it'll be used with FEATURES=buildpkg, which I have set
and recommend as a very useful feature, as well as when a previously built
binary package is merged using -k or -K.  (The buildpkg FEATURE doesn't do
the usual ebuild qmerge step, but rather merges from the binary package
just created, thus testing it, using PKG_TMPDIR in the process.)  Note
that you only need to point the var at /tmp, as portage automatically uses
the binpkgs subdir of whatever it's pointed at, just as it uses the
portage subdir of PORTAGE_TMPDIR during the build process.

Interesting it doesn't seem to be documented, and PORTAGE_TMPFS is in
make.conf.example, but not in the make.conf manpage.  I should file a bug.

-- 
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@gentoo.org mailing list



  reply	other threads:[~2006-11-08 15:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-05  8:45 [gentoo-amd64] Unexpected side effect of GCC 4 Peter Humphrey
2006-11-05 10:12 ` [gentoo-amd64] " Duncan
2006-11-05 11:50   ` Peter Humphrey
2006-11-05 12:10     ` Peter Humphrey
2006-11-06  8:17       ` Duncan
2006-11-06  8:29         ` Hemmann, Volker Armin
2006-11-06 15:57           ` Duncan
2006-11-06  7:50     ` Duncan
2006-11-06  8:48       ` Peter Humphrey
2006-11-06 16:01         ` Duncan
2006-11-06 16:06         ` Peter Humphrey
2006-11-06  8:41     ` Duncan
2006-11-06 10:47       ` Hemmann, Volker Armin
2006-11-06 11:48         ` Peter Humphrey
2006-11-06 12:05           ` Hemmann, Volker Armin
2006-11-06 12:49             ` Jack Lloyd
2006-11-06 12:59               ` Hemmann, Volker Armin
2006-11-06 13:06                 ` Jack Lloyd
2006-11-06 15:06                 ` Peter Humphrey
2006-11-06 11:44       ` Peter Humphrey
2006-11-06 15:51         ` Duncan
2006-11-08 11:19           ` Peter Humphrey
2006-11-08 15:17             ` Duncan [this message]
2006-11-10 10:14               ` Peter Humphrey
2006-11-05 13:24   ` Hemmann, Volker Armin
2006-11-05 23:26     ` Duncan
2006-11-08 10:14 ` [gentoo-amd64] " Peter Humphrey
2006-11-08 11:06   ` [gentoo-amd64] " Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='eissei$dvt$1@sea.gmane.org' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox