Talk:Portage TMPDIR on tmpfs

Redundant for systemd users?
tmpfs is already mounted on /tmp thanks to /usr/lib/systemd/system/tmp.mount on systems using Systemd. Therefore, don't Systemd users with default PORTAGE_TMPDIR automatically build in RAM? --Shoaloak (talk) 21:30, 31 May 2017 (UTC)


 * Hi, this article is not mentioning , it is mentioning some directories under because this is where Portage stores its temporary directories ( for example). Hope this helps. --Maffblaster (talk) 22:30, 31 May 2017 (UTC)

Something about TMPDIR that I wanted to know when reading this page.
Note that the value of Portage's TMPDIR used here is the default value /var/tmp and can be verified by executing emerge --info|grep ^PORTAGE_TMPDIR. Portage does it's magic in a subdir called portage, hence why /var/tmp/portage is used above. --EmanueLczirai (talk) 17:55, 6 January 2015 (UTC)


 * The article has reflected that for a while. Count it fixed. :) --Maffblaster (talk) 16:38, 8 June 2016 (UTC)

tmpfs within tmpfs
Worth noting that if /var/tmp/ is already tmpfs and you still want to mount /var/tmp/portage as tmpfs from /etc/fstab then the option x-mount.mkdir will help(without it /vat/tmp/portage/ folder won't exist and mount will fail). It may look something like this for example(in my case): --EmanueLczirai (talk) 05:48, 15 January 2015 (UTC)


 * Excellent tip. I'll note it in the main article for now, but please feel free to add things like this yourself. The community would love your tips! :) --Maffblaster (talk) 05:32, 22 March 2017 (UTC)

Page move
Unless there are objections I believe it would be good to move this article to be a sub-article of Portage. This article is directly connected to Portage and (to me) it does not make too much sense to leave it dis-conjoined from the Portage article. The new location would either be Portage/TMPDIR or Portage/TMPDIR on tmpfs. We can either choose to call it the variable game, for simply use the suffix of the currently existing name and move it under Portage. Let me know if there are any objects and the reasoning behind them. I'll clean up any links that would link to the old location. --Maffblaster (talk) 15:58, 27 May 2015 (UTC)


 * You seem to like attaching subpages. IMHO having a reasonable page title is much more important and putting links on relevant places does not leave any need for subpages.  ... On the other hand, subpages tend to have a long name that is hard to remember, so it may be more user-friendly to use them as little as possible. You can also organize pages with the category feature, which is more suitable for creating a hierarchical network of information.    --Charles17 (talk) 16:28, 27 May 2015 (UTC)


 * I'd rather think of it as a tree, or URL, or folder structure. It's the same thing for the /etc/portage article and other articles. It seems to me that it's easier for users to find related content if it's organized with similar URLs, like a normal website (not a Wiki). The Wiki includes a nice search function, but that doesn't mean people should be forced to use it in order to find the pages they are looking for.


 * Thinking of hierarchical structure, to which article Overlay or /etc/portage/repos.conf if not to both of them would you attach that other new one as a subarticle? --Charles17 (talk) 17:23, 27 May 2015 (UTC)


 * To support my point, there's the Xfce article and the guide version of the article is Xfce/Guide rather than Xcfe Guide (an entirely separate article). If the reader wants to get deeper information on an article they can simply type /Guide on the end of the software in question to get a longer, deeper article.


 * To my personal sad experience most people like clicking on links instead of using the urlbar of their browser. So some links should be places anyway. I don't see any benefit of having subarticles.   --Charles17 (talk) 17:23, 27 May 2015 (UTC)


 * I've been trying to keep a theme of connecting articles if they only related to a single piece of software. Since this article directly deals with TMPDIR exclusively for Portage, it makes a lot of sense to me to make the move. Categories can still be used if you'd like in order to link things. I'm not saying that we have to move it to be a sub-article of Portage, but I definitely think it needs some kind of title change to help readers more easily find it. --Maffblaster (talk) 16:46, 27 May 2015 (UTC)


 * Still not worth wasting your time with considerations about subarticles. Much better investment of time is placing links in all related places where readers might like to find more information. --Charles17 (talk) 17:23, 27 May 2015 (UTC)


 * Charles old buddy, old pal. I'd still like to make this a sub-article of Portage, but I be happy with how it is currently and mark this discussion as closed. :) --Maffblaster (talk) 16:42, 8 June 2016 (UTC)

Not enough 2GB on tmpfs info
For virtualbox-5.0.20 not enough 2GB on tmpfs (/var/tmp/portage) for me. app-emulation/wine dev-lang/mono dev-lang/rust --Cronolio (talk) 03:30, 30 June 2016 (UTC)


 * Sure. Lets increase the size to 4GBs. That should be enough. It is not enough then increase it more. :) --Maffblaster (talk) 05:30, 22 March 2017 (UTC)


 * send me space for this! :) --Cronolio (talk) 15:06, 17 June 2017 (UTC)

Running out of inodes on tmpfs
Is what actually happened in my case, when trying to build www-client/chromium-57.0.2987.98 (and 56 before that). Having 16G of RAM, I've had allocated 4G for PORTAGE_TMPDIR on tmpfs. But the emerge complained on the lack of free space during unpack. Increasing tmpfs size gradually - 5G, 6G, 8 .. 12G did nothing to help. Surprisingly(for me), actual size of unpacked data never exceeded ~2G - the point after which out-of-space message started showing up. That triggered some suspicion. So, having found some docs on the topic... tmpfs.txt I've applied the mount' option nr_inodes=0 to fix possible lack of inodes. After that, unpack went smoothly and build completed successfully. There's possible downside to having nr_indodes with value equal "0"(unlimited amount of possible inodes created), so actual value may be amended to your taste. Some more information on that here http://serverfault.com/questions/524419/why-dont-linux-distributions-default-to-mounting-tmpfs-with-infinite-inodes

Asking mods to reflect my point in troubleshooting section(sorry, my wiki-fu is not nearly strong enough to handle it neatly). — The preceding unsigned comment was added by D-ion (talk • contribs) March 23, 2017‎


 * Hi,, this is very interesting. Thanks for the tip! Can you integrate this into a Troubleshooting section of the article? Also, be sure to sign your comments to discussion pages (see the little button in the edit toolbox). I will fix the first one for you. Kind regards, --Maffblaster (talk) 18:09, 23 March 2017 (UTC)


 * I'm new to this so, please, bear with me. Tried accommodating the workaround into the section. --D-ion (talk) 23:51, 27 March 2017 (UTC)


 * , no problem. I see you added it to the Troubleshooting section. Thanks for contributing! I'll mark this discussion as closed. Kind regards, --Maffblaster (talk) 23:54, 27 March 2017 (UTC)

Memory usage for gcc-9 is > 4GB...
I just compiled stable gcc on ppc64, and my tmpfs is set to 4G, and the build failed with "No space left on device" while being 3983m big. sys-devel/gcc-9.3.0-r1:9.3.0::gentoo [8.3.0-r1:8.3.0::gentoo] USE="altivec (cxx) fortran nls nptl openmp pch (pie) sanitize ssp (-ada) -d% -debug -doc (-fixed-point) -go -graphite (-hardened) -jit (-libssp) -lto% (-multilib) -objc -objc++ -objc-gc -pgo -systemtap -test -vanilla (-vtv) (-mpx%)" Since neither Java nor Objective-C are enabled, I changed the article accordingly. I don't think it's specific to ppc64... Luttztfz (talk) 04:39, 17 September 2020 (UTC)