From 4b09123e9b0554ed67937ca00a5c4cfd3f9c43ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
Date: Fri, 24 Jul 2020 22:05:21 +0200
Subject: [PATCH] Bump /tmp size back to 50% of RAM

This should be enough to fix https://bugzilla.redhat.com/show_bug.cgi?id=1856514.
But the limit should be significantly higher than 10% anyway. By setting a
limit on /tmp at 10% we'll break many reasonable use cases, even though the
machine would deal fine with a much larger fraction devoted to /tmp.
(In the first version of this patch I made it 25% with the comment that
"Even 25% might be too low.". The kernel default is 50%, and we have been using
that seemingly without trouble since https://fedoraproject.org/wiki/Features/tmp-on-tmpfs.
So let's just make it 50% again.)

See 7d85383edbab73274dc81cc888d884bb01070bc2.

(Another consideration is that we learned from from the whole initiative with
zram in Fedora that a reasonable size for zram is 0.5-1.5 of RAM, and that pretty
much all systems benefit from having zram or zswap enabled. Thus it is reasonable
to assume that it'll become widely used. Taking the usual compression effectiveness
of 0.2 into account, machines have effective memory available of between
1.0 - 0.2*0.5 + 0.5 = 1.4 (for zram sized to 0.5 of RAM) and
1.0 - 0.2*1.5 + 1.5 = 2.2 (for zram 1.5 sized to 1.5 of RAM) times RAM size.
This means that the 10% was really like 7-4% of effective memory.)
---
 units/tmp.mount | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/tmp.mount b/units/tmp.mount
index 7066e52261..cf6837852f 100644
--- a/units/tmp.mount
+++ b/units/tmp.mount
@@ -22,4 +22,4 @@ After=swap.target
 What=tmpfs
 Where=/tmp
 Type=tmpfs
-Options=mode=1777,strictatime,nosuid,nodev,size=10%,nr_inodes=400k
+Options=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=400k