From owner-freebsd-stable@FreeBSD.ORG Sat Jan 23 20:21:50 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 6735E106568F for ; Sat, 23 Jan 2010 20:21:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD638FC24 for ; Sat, 23 Jan 2010 20:21:49 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Z7qi1d0010vp7WLAC8Mq6v; Sat, 23 Jan 2010 20:21:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id Z8Mp1d00W3S48mS8R8MqZW; Sat, 23 Jan 2010 20:21:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B75EC1E3033; Sat, 23 Jan 2010 12:21:48 -0800 (PST) Date: Sat, 23 Jan 2010 12:21:48 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100123202148.GA22096@icarus.home.lan> References: <20100122162155.GG3917@e-Gitt.NET> <20100122170716.GA75020@icarus.home.lan> <4B5B5669.9080906@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5B5669.9080906@quip.cz> User-Agent: Mutt/1.5.20 (2009-06-14) 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 20:21:50 -0000 On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > Jeremy Chadwick wrote: > > [...] > > >While I'm here, I figure I'd share how I end up partitioning most of the > >server systems I maintain. I use this general "formula" when building a > >new system, unless it's a 4-disk box (see bottom of mail): > > > >ad4s1a = / = UFS2 = 1GB > >ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) > >ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be>= 2*RAM) > >ad4s1e = /tmp = UFS2+SU = (2*RAM) > >ad4s1f = /usr = UFS2+SU = 16GB > > Why you are suggesting /var >= 2*RAM? Is it just for saving crash > dumps or anything else? 1) Kernel panics/crash dumps are a big focus, yes. There's nothing worse than experiencing one, only to find out that savecore(8) can't do its job because /var/crash lacks the space. The system then boots anyway, swap starts getting used as normal, and the dump is therefore lost. Chance of debugging this post-mortem: zero. Additionally, people these days are often upgrading RAM in their systems as well; they start out with 1-2GB and create /var possibly with the knowledge of the above ordeal (re: crash dumps). Then they later upgrade to 4GB or 8GB RAM, and suddenly realise that they can't grow /var to deal with a crash dump. 2) I tend to keep a large amount of logs on systems, going back weeks if not months. This is intentional; it's amazing how often a customer or user will ask for some information from 3 or 4 months prior. FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what we do is mostly web content serving. Let's also not forget about /var/log/maillog. I also advocate use of /var/log/all.log. I think it's fairly well-established at this point that I focus on server environments and not workstations (where /var probably doesn't need to be anywhere near that size). Folks should always review their needs, keeping expansion possibility in mind, when doing filesystem creation. > 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). "So tune lynx to use /var/tmp or some other path" -- sure, that'd work, except lynx is just one of many programs which could do this. I'd rather not "tune them all". :-) /tmp is more or less universal. Hope this sheds some light on my decisions. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |