From owner-freebsd-arch Sat Dec 8 20:13:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C6C7937B405 for ; Sat, 8 Dec 2001 20:13:40 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id XAA22189; Sat, 8 Dec 2001 23:13:34 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id fB94D9I08632; Sat, 8 Dec 2001 23:13:09 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.58581.711516.632169@grasshopper.cs.duke.edu> Date: Sat, 8 Dec 2001 23:13:09 -0500 (EST) To: Matthew Dillon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112080543.fB85hSt00738@apollo.backplane.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <15377.41198.83638.460387@grasshopper.cs.duke.edu> <200112080543.fB85hSt00738@apollo.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > :Let's not forget /var/crash. I always make var at least twice as > :large as the physical memory in the box, plus some slop, so I have > :enough room to hold 2 crashdumps. <..> > > That's problematic. /var's size requirements tend to > be fairly static, unrelated to the amount of memory > the machine might have. A machine that doesn't act > as a mail spool or repository generally doesn't need > a large /var. So if you have a machine with 512M of > ram and we create a 1G /var it will almost certainly > remain 99% empty for the entire life of the machine. > > The only time I have ever created a /var larger then > 512M is on mail relays and shell machines with > thousands of users. > > So creating a /var based on available physical ram > is problematic. If your machine has a lot of memory > you will almost certainly be wasting a huge amount > of disk space for a /var that will never get more > then 1% full (except for the occassional crash dump) > It isn't worth it. > > What I do, personally, is cap /var at 512M and if > I have a machine with more memory and I want > crash dumps I softlink /var/crash to either > /usr/var.crash, or /home/var.crash. Or I run > savecore manually to another directory after > boot. Yeah, this is what I do when I have a machine whose disk is tiny. > My recommendation for auto-generating /var is > that we not make it larger then 512M. Then our location of /var/crash appears to be in confict with the purpose of /var, so we should move /var/crash to /usr/crash, or teach "dump" to be smarter & not dump the entire memory of the machine in the first place. Eg, don't dump vnode backed pages, free pages, or portions of the address space which aren't backed by physical memory.. FWIW, Tru64 does this (or something like it, its crashdumps are tiny). Totally off topic, but they optionally do a compressed dump to ram & hand that chunk of memory to savecore on a reboot. Quite slick. I really appreciate your efforts to make the partiton size defaults more sane. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message