From owner-svn-src-stable@FreeBSD.ORG Thu Sep 10 15:43:35 2009 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C462B106566B; Thu, 10 Sep 2009 15:43:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97B798FC15; Thu, 10 Sep 2009 15:43:35 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4213A46B53; Thu, 10 Sep 2009 11:43:35 -0400 (EDT) Date: Thu, 10 Sep 2009 16:43:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200909101118.22525.jhb@freebsd.org> Message-ID: References: <200909101404.n8AE41C6021588@svn.freebsd.org> <200909101023.44913.jhb@freebsd.org> <1252593149.75144.18.camel@bauer.cse.buffalo.edu> <200909101118.22525.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-8@freebsd.org, Ken Smith , Ken Smith Subject: Re: svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 15:43:35 -0000 On Thu, 10 Sep 2009, John Baldwin wrote: >> It has been pointed out to me on the mailing lists that leaving it on for >> stable/7 was an oversight, it is off on previous branches. >> >> I can understand the motivation for it. In a data center full of >> production machines crash dumps cause reboots to take longer and >> potentially cause disk space issues. In those sorts of environments it's >> best if by *default* the crash dumps don't happen and if an admin finds >> they need it they turn it on. >> >> This is one of those "There is no right answer" things... > > Hmm, I thought the crashdumps were a conscious descision as part of another > change in 7.x (shipping with debug symbols enabled by default) to try to > make it easier to get more useful crash reports from stock kernels. Having > the debug symbols present is probably enough for that though since it is > fairly easy to enable crashdumps in rc.conf vs. having to build a new kernel > just to get debug symbols. Should we change the default behavior in 7? I wonder if we could teach libkvm how to work directly from a crashdump in situ in the swap partition? This would not fix "slower reboot times" but it would help a lot with the "running out of disk space" thing. I see no reason at all we shouldn't be logging things like panics/stack traces for every crash in our normal logs -- in fact, that was much of the motivation for text dumps (and crashinfo too, no doubt): capture critical crash information in a compact way that can be e-maile around, etc, without the overhead of multi-gig dumps. Teaching libkvm how to work on crash dump partitions would let us avoid having the crashdump reside in the file system and help a lot with that problem. Robert N M Watson Computer Laboratory University of Cambridge