Debian's /tmpest in a teapot

Posted Jun 4, 2024 16:27 UTC (Tue) by gray_-_wolf (subscriber, #131074)
In reply to: Debian's /tmpest in a teapot by smurf
Parent article: Debian's /tmpest in a teapot

I fail to see how `-j whatever' relates to usage in /tmp. Peak RAM usage I do see the connection, but not for the disk space. Without -j the disk usage will grow slower, but it will reach the same total peak number.

My point being that there are programs that legitimately use many gigabytes in /tmp, and "tmpfs with max size of 1/2 of RAM" will just not work for them. I took guix package of an example that is packaged by debian, and therefore it seems reasonable to have it work out of the box.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 16:31 UTC (Tue) by bluca (subscriber, #118303) [Link]

Such packages can simply be configured to use something else like /var/tmp, then

Debian's /tmpest in a teapot

Posted Jun 5, 2024 1:56 UTC (Wed) by nakedhitman (subscriber, #90828) [Link] (3 responses)

> I fail to see how `-j whatever' relates to usage in /tmp.

Depending on what you're compiling, each compilation thread will use up to a certain amount of temp space. That bit me a few times, but once I knew what it was, I was easily able to work around it.

> My point being that there are programs that legitimately use many gigabytes in /tmp, and "tmpfs with max size of 1/2 of RAM" will just not work for them.

tmpfs will work just fine for use cases that exceed the size of RAM. Just add swap (even better with zswap) and size accordingly. That was the solution in my case, and my system has been better for it overall. Systems really should be using swap anyway, and tmpfs should default to using a size that matches either swap or 50% RAM, whichever is greater.

build systems & /tmp

Posted Jun 5, 2024 20:20 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (2 responses)

> Depending on what you're compiling, each compilation thread will use up to a certain amount of temp space. That bit me a few times, but once I knew what it was, I was easily able to work around it.

Out of curiosity: which build systems place significant amounts of data in /tmp, even temporarily? And for what? With "significant" I mean more than a handful of KB per compilation process so that the total amount can become significant enough.

build systems & /tmp

Posted Jun 6, 2024 8:17 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

> which build systems place significant amounts of data in /tmp, even temporarily?

The result of preprocessing a ten-line C or C++ file can and will easily span multiple megabytes.

Same for the intermediate assembly output, esp. when you add debugging.

build systems & /tmp

Posted Jun 6, 2024 15:25 UTC (Thu) by mbunkus (subscriber, #87248) [Link]

Right… Before posting my comment I had done a quick strace with one of the clang++ calls used in project's build process and saw no write to /tmp. Re-configuring to g++ I do actually see it writing the assembly files to /tmp. It can be avoided by adding -pipe.