From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 21:46:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FBD11065696 for ; Sat, 23 Jan 2010 21:46:30 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id CA6058FC12 for ; Sat, 23 Jan 2010 21:46:29 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id EAE2710168; Sat, 23 Jan 2010 11:46:28 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id A1E15153882; Sat, 23 Jan 2010 11:46:28 -1000 (HST) Date: Sat, 23 Jan 2010 11:46:28 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20100123214628.GA10271@lava.net> Mail-Followup-To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> <4B5B5669.9080906@quip.cz> <20100123202148.GA22096@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123202148.GA22096@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 21:46:30 -0000 On Sat, Jan 23, 2010 at 12:21:48PM -0800, Jeremy Chadwick wrote: > On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > > Jeremy Chadwick wrote: ... > > And why so big /tmp? I am running servers with smaller sizes for years > > without any problem. > > My recommendation above doesn't imply those who don't use it will have > problems -- each environment/system is different. > > That said, it's amazing how much software out there blindly uses /tmp. > Last year I ran into this situation: an older server (1GB /tmp) started > behaving oddly due to /tmp filling. A user of the system was using lynx > to download some large files (an ISO image and something else, I forget > what). lynx saves data its downloading to /tmp, and once it completes, > the user is prompted where to save the data (CWD being the default). Another example: the stock /usr/bin/sort uses /tmp for its temporary storage when it needs to start using disk. You can redirect that via -T if you think ahead and realize that it's going to be a problem, but if you are just whipping up a quick shell script and later happen to run it on much bigger inputs than you were expecting you can run out of space on /. (Yes, that happened to me fairly recently on several systems, when some log files weren't being rotated on schedule.) An alternative solution is to symlink /tmp to /var/tmp, which I've done on many systems, assuming that nothing in the /etc/rc sequence will need /tmp before filesystems are mounted. (I suppose putting it on its own filesystem also assumes that.) In general, I think you've got a good idea and I plan to start adopting that in the future. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services