Date: Sat, 8 Dec 2001 23:13:09 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <15378.58581.711516.632169@grasshopper.cs.duke.edu> 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> <p05101006b83737546907@[128.113.24.47]> <200112080349.fB83nWU00292@apollo.backplane.com> <15377.41198.83638.460387@grasshopper.cs.duke.edu> <200112080543.fB85hSt00738@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15378.58581.711516.632169>