Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 597496 - Provide a way to automatically mount a tmpfs on $PORTAGE_TMPDIR
Summary: Provide a way to automatically mount a tmpfs on $PORTAGE_TMPDIR
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-19 00:04 UTC by George Diamantopoulos
Modified: 2016-10-19 01:23 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Diamantopoulos 2016-10-19 00:04:21 UTC
As I rely on SSD storage (and because sometimes it's a lot faster), I usually employ tmpfs for $PORTAGE_TMPDIR, since I tend to upgrade/test packages often. I don't have it mount automatically, since I'd like memory to be available for other purposes if I'm not doing an emerge/ebuild operation.

I would like to explore the possibility of providing a mechanism to automatically mount a tmpfs filesystem on $PORTAGE_TMPDIR every time it's needed. I'm not saying this should be a hook ebuilds could choose to use or not, I'm saying it could be an option perhaps in make.conf like AUTOMOUNT_TMPFS=yes/no which (if set) would check fstab and mount the respective filesystem every time a pkg_setup or src_unpack is called and unmount it after a successful merge.

Perhaps there could also be a way to provide a user-defined range for the size of such a tmpfs (again in make.conf, say 2-8GB), which would automagically expand the size of tmpfs to match CHECKREQS_DISK_BUILD (if and only if its value is within the range provided), otherwise always use the minimum of the range provided.

I'm not sure of the feasibility of such a feature (or difficulty of implementation), so I'm posting it here. One caveat I can think of is for cases when we don't want $PORTAGE_TMPDIR cleaned, and another unpack-merge cycle is queued, for example when a user uses --keep-going (so that build logs etc are available later). In that case a workaround could be to never unmount $PORTAGE_TMPDIR during the entire emerge (instead of unmounting after every sucessful merge). In such a case, tmpfs could fill up if there are many failed packages, but this happens anyway with manual mounting which is what we're doing now.

Another (perhaps more important conflict) would arise in case multiple emerges are issued, or when an emerge is in progress and the user executes "ebuild package.ebuild action". In that case you can't have portage preemptively unmount tmpfs after a merge, if another emerge is in progress... Is this manageable without considerable refactoring of the code?

Any thoughts?

Reproducible: Always
Comment 1 Zac Medico gentoo-dev 2016-10-19 01:23:32 UTC
Most people just use a permanent tmpfs mount on /var/tmp/portage, along with FEATURES="fail-clean".