From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 13:16:25 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86721F63 for ; Sun, 9 Jun 2013 13:16:25 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id F1F151985 for ; Sun, 9 Jun 2013 13:16:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r59DGNIe088449; Sun, 9 Jun 2013 17:16:23 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 9 Jun 2013 17:16:23 +0400 (MSK) From: Dmitry Morozovsky To: Jeremy Chadwick Subject: Re: /tmp: change default to mdmfs and/or tmpfs? In-Reply-To: <20130609124603.GA35681@icarus.home.lan> Message-ID: References: <20130609124603.GA35681@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sun, 09 Jun 2013 17:16:23 +0400 (MSK) 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:16:25 -0000 On Sun, 9 Jun 2013, Jeremy Chadwick wrote: > > 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" > > Hold up. Let's start with what you just gave. Everything I'm talking > about below is for stable/9 by the way: Don't mix md-backed tmp with tmpfs, see below: > 1. grep -r tmpfs /etc returns nothing, so I don't know where this magic > comes from, it is /etc/rc.d/tmp with tmpmfs_* rc variables actually > 2. tmpfs(5) documents none of these flags, and the flags you've given > cannot be mdconfig(8) flags because: > > a) -S requires a sector size (you specified none), > b) -n would have no bearing given the context, > c) -o async applies only to vnode-backed models (default is malloc, > and I see no -t vnode), > d) There is no -b flag, > e) The -f flag is for -t vnode only, and refers to a filename for the > vnode-backing store. all these are related to mdmfs(8) > So consider me very, very confused with what you've given. Maybe the > flags were different on FreeBSD 6.x or 7.x or 8.x? I haven't checked > http://www.freebsd.org/cgi/man.cgi yet. Actually, there are two different questions (or kind of questions): - are we considering switching off /tmp from real media-backed storage? - is so, what are we selecting: memory/swap-backed UFS (mdmfs) or tmpfs? > As I understand it, there are (or were -- because I remember seeing them > repeatedly brought up on the mailing lists) problems with tmpfs. > Sometimes these issues would turn out to be with other filesystems (such > as unionfs), but other times not so much. > > If my memory serves me correct, there are major complexities with > VM/memory management when intermixing tmpfs + ZFS + UFS on a system***. Yes, hence my question about status of tmpfs now. And yes, I personally do *not* used tmpfs-backed /tmp on real productionj servers -- just mdmfs-backed. OTOH, I *do* use tmpfs for my builder (for tinderbox for now, but I'm planning switch buildworld/buildkernel there too), with little issues yet. [snip the rest, I have to dig a bit more to answer] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------