From owner-svn-src-head@FreeBSD.ORG Wed Sep 22 21:53:48 2010 Return-Path: <owner-svn-src-head@FreeBSD.ORG> Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9E13106566C; Wed, 22 Sep 2010 21:53:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 99C628FC08; Wed, 22 Sep 2010 21:53:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 48C0D46B46; Wed, 22 Sep 2010 17:53:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 415F58A04E; Wed, 22 Sep 2010 17:53:47 -0400 (EDT) From: John Baldwin <jhb@freebsd.org> To: Ken Smith <kensmith@buffalo.edu> Date: Wed, 22 Sep 2010 17:53:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009211507.o8LF7iVv097676@svn.freebsd.org> <4C9A6EE6.5050301@freebsd.org> <4C9A71ED.6020406@buffalo.edu> In-Reply-To: <4C9A71ED.6020406@buffalo.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009221753.21408.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 22 Sep 2010 17:53:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gavin Atkinson <gavin@freebsd.org>, src-committers@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head> List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 21:53:48 -0000 On Wednesday, September 22, 2010 5:15:25 pm Ken Smith wrote: > On 9/22/10 5:02 PM, Andriy Gapon wrote: > > on 22/09/2010 22:58 John Baldwin said the following: > > > >> Agreed. FWIW, I actually think that this is the only change needed as > >> crashinfo is enabled by default in 8.x and later. We already include symbols > >> in kernels by default now, so just setting dumpdev will give you the same > >> info you generally can get from a textdump in the form of a simple > >> /var/crash/core.txt.N file. > >> > >> The other benefit of full crashdumps + crashinfo as compared to textdumps is > >> that a developer can request further information in a PR followup (fire up > >> kgdb and enter command 'X' and reply with the output). With a textdump any > >> info not collected by the textdump is lost once the machine reboots after the > >> crash. > > > > Agree++ > > But what was the reason that dumpdev="AUTO" was reverted? > > I remember that POLA was quoted at the time. > > I am not sure what the astonishment actually was - perhaps 'AUTO' was not smart > > enough and destroyed somebody's data? > > > > > Not everybody would notice /var getting full of crash dumps. > Picture a server farm where for the most part the machines > are all just plain on auto-pilot. If one or several develop > a problem that causes panic's /var can become full and possibly > cause the machine to stop doing something important (between > panic's...). I wasn't around when the initial decision for > what to have it set to was made but this was the reason for > me starting to do it again when I realized I forgot to at > least once, and hence the reference to POLA. > > Crash dumps are good for individual workstations. Crash > dumps are good for servers *if* the admin knows they're > having a problem and is actively working on that server > to resolve the issue. But they're no so good and can > cause nasty side-effects if they're happening on a machine > not being watched over closely. That's the reason for > the change in setting when a -stable branch gets started. FWIW, the Y! version of crashinfo auto-deletes crash dumps based on the available disk space for precisely this reason. With that addition crashinfo works quite well on a very large server farm. -- John Baldwin