From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 85D95139694 for ; Wed, 24 May 2017 05:34:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9473821C124; Wed, 24 May 2017 05:34:39 +0000 (UTC) Received: from synchrony.c-14.de (sthelen.eu [IPv6:2a01:4f8:c17:6b43::b:17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37116E0E8C for ; Wed, 24 May 2017 05:34:39 +0000 (UTC) Received: from sardaukar.c-14.de (HSI-KBW-134-3-145-106.hsi14.kabel-badenwuerttemberg.de [134.3.145.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by synchrony.c-14.de (Postfix) with ESMTPSA id B459A64911 for ; Wed, 24 May 2017 05:32:46 +0000 (UTC) Date: Wed, 24 May 2017 07:34:34 +0200 From: gentoo-user@c-14.de To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] tmp on tmpfs Message-ID: <20170524053434.GA2656@anonymous> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20170524051002.12325.12B52329@matica.foolinux.mooo.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170524051002.12325.12B52329@matica.foolinux.mooo.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-Archives-Salt: 0fadb6ff-45d8-4411-81b8-bf8caf7db02c X-Archives-Hash: 68612d5dc56f025e9c07db0233dfca32 On 17-05-23 at 22:16, Ian Zimmerman wrote: > So what are gentoo users' opinions on this matter of faith? I use an ext4 partition backed by zram. Gives me ~3x compression on the things I normally have lying around there (plain text files) and ensures that anything I throw there (or programs throw there) gets cleaned up on reboot. > I have long been in the camp that thinks tmpfs for /tmp has no > advantages (and may have disadvantages) over a normal filesystem like > ext3, because the files there are normally so small that they will stay > in the page cache 100% of the time. I've never actually benchmarked this. Most of the things I notice that tend to end up there are temporary build files generated during configure stages or temporary log files used by various programs (clang static analyzer). Even if the entire file stays in the page cache, it'll still generate IO overhead and extra seeks that might slow down the rest of your system (unless your /tmp is on a different hard drive) which on spinning rust will cause slowdowns while on an ssd it'll eat away at your writes (which you may or may not have to worry about). > But I see that tmpfs is the default with systemd. Surely they have a > good reason for this? :) Or someone decided they liked the idea and made it the default and nobody ever complained (or if they did were told to just change it on their system). Either way, it'd be nice if someone actually benchmarked this. -- Simon Thelen