Add emerge --jobs-tmpdir-space-threshold option

[zmedico]

--jobs-tmpdir-space-threshold[=RATIO]

Specifies the maximum ratio of used space allowed (a floating-point number) in PORTAGE_TMPDIR when starting a new job. With no argument, removes a previous space ratio threshold. For example, use a ratio of 0.85 to stop starting new jobs when the space usage in PORTAGE_TMPDIR exceeds 85%.

Bug: https://bugs.gentoo.org/934382

[Flowdalic]

In no way I object this change.

But I believe we should eventually come to a point where we are (also) able to specify absolute thresholds besides a relative one. The two relevant resources in question are free disk space and free inodes. Ideally we could gather some data about the worst-case disk space and inode consumption after src_compile and use those worst-case values (plus a small additional safety margin) as default thresholds. Maybe we could gather some worst-case data from the tinderboxes?

But this is mostly unrelated to the change proposed to this PR. Though, I personally would probably have implemented absolute threshold parameters for free disk space and inodes first, and not a relative one.

[zmedico]

Though, I personally would probably have implemented absolute threshold parameters for free disk space and inodes first, and not a relative one.

Since ratios have no units, it was simpler to implement this threshold as a ratio. I was thinking we could possibly re-use the same option for absolute thresholds if we add support for parsing units.

[zmedico]

We could make it possible to distinguish between used space or remaining space, using a plus or minus operator for example.

[Flowdalic]

Sure, an inode threshold could possibly be useful, but in this context running out of inodes seems likely to indicate that the user statically allocated an insufficient number of inodes.

Probably, still @akhuettel ran into inode exhaustion, not free-space. Of course, you could argue that it was a filesystem configuration error of the user, which would otherwise potentially go unnoticed.

I think these thresholds probably depend too much on the user's PORTAGE_TMPDIR configuration for defaults to be really meaningful.

I am a little bit ore optimistic here.

Sure, no (sane) default could prevent portage from running into filesystem-based resource exhaustion. Still, even without performing a throughout analysis of the worst-case file-system space and inode consumption of packages in ::gentoo, we could probably come up with a reasonable default threshold for free filesystem space and inodes. Just pick some good candidates, for example, firefox, chrome, compilers, and, of course libre office, to get an idea of their filesystem resource consumption, and then multiply by some factor, probably taking the number of concurrent portage jobs into account, as safety margin to get an idea what an initial default value could be.

[zmedico]

Sure, an inode threshold could possibly be useful, but in this context running out of inodes seems likely to indicate that the user statically allocated an insufficient number of inodes.

Probably, still @akhuettel ran into inode exhaustion, not free-space. Of course, you could argue that it was a filesystem configuration error of the user, which would otherwise potentially go unnoticed.

Now that I've added --jobs-merge-wait-threshold in #1349, it has occurred to me that it can help to prevent inode exhaustion, since inode consumption would be partially related to the merge-wait queue length.

[zmedico]

Sure, an inode threshold could possibly be useful, but in this context running out of inodes seems likely to indicate that the user statically allocated an insufficient number of inodes.

Probably, still @akhuettel ran into inode exhaustion, not free-space. Of course, you could argue that it was a filesystem configuration error of the user, which would otherwise potentially go unnoticed.

Now that I've added --jobs-merge-wait-threshold in #1349, it has occurred to me that it can help to prevent inode exhaustion, since inode consumption would be partially related to the merge-wait queue length.

Closing this in favor of #1351 which distinguishes between both used blocks and used files (inodes).

[zmedico]

I think these thresholds probably depend too much on the user's PORTAGE_TMPDIR configuration for defaults to be really meaningful.

I am a little bit ore optimistic here.

Sure, no (sane) default could prevent portage from running into filesystem-based resource exhaustion. Still, even without performing a throughout analysis of the worst-case file-system space and inode consumption of packages in ::gentoo, we could probably come up with a reasonable default threshold for free filesystem space and inodes. Just pick some good candidates, for example, firefox, chrome, compilers, and, of course libre office, to get an idea of their filesystem resource consumption, and then multiply by some factor, probably taking the number of concurrent portage jobs into account, as safety margin to get an idea what an initial default value could be.

In addition to the number of jobs, an automatically calculated threshold might also account for the baseline usage in PORTAGE_TMPDIR at the time that emerge is started, in case this file-system has some pre-existing content either inside or outside of ${PORTAGE_TMPDIR}/portage. I suppose FEATURES=fail-clean or lack thereof is another thing we might want to account for somehow.