From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 13:25:56 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 707E0458 for ; Sun, 9 Jun 2013 13:25:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 35B4819C6 for ; Sun, 9 Jun 2013 13:25:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r59DPtKv070635; Sun, 9 Jun 2013 07:25:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r59DPtLM070632; Sun, 9 Jun 2013 07:25:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 9 Jun 2013 07:25:55 -0600 (MDT) From: Warren Block To: Dmitry Morozovsky Subject: Re: /tmp: change default to mdmfs and/or tmpfs? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 09 Jun 2013 07:25:55 -0600 (MDT) Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 13:25:56 -0000 On Sun, 9 Jun 2013, Dmitry Morozovsky wrote: > Dear colleagues, > > what do you think about stop using precious disk or even SSD resources for > /tmp? > > For last several (well, maybe over 10?) years I constantly use md (swap-backed) > for /tmp, usually 128M in size, which is enough for most of our server needs. > Some require more, but none more than 512M. Regarding the options, we use > tmpmfs_flags="-S -n -o async -b 4096 -f 512" > > Given more and more fixes/improvements committed to tmpfs, switching /tmp to it > would be even better idea. > > You thoughts? Thank you! tmpfs has been working fine here for /tmp. I also use it for /usr/obj. It does not tie up a fixed chunk of RAM, and can grow to large sizes if necessary. And maximum size can be limited in fstab. (Possible improvement: allow human-readable sizes instead of just blocks.) One problem is that tmpfs is cleared by a reboot. This would surprise users expecting the default behavior (clear_tmp_enable="NO"), and would require some prominent warnings in the release notes and maybe in the installer. Or in the startup scripts: "/tmp on tmpfs, contents will be discarded on reboot".