From owner-svn-src-projects@FreeBSD.ORG Thu Jan 27 19:56:20 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C772106567A; Thu, 27 Jan 2011 19:56:20 +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 EFF5B8FC17; Thu, 27 Jan 2011 19:56:19 +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 8546746B39; Thu, 27 Jan 2011 14:56:19 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 73B248A009; Thu, 27 Jan 2011 14:56:18 -0500 (EST) From: John Baldwin To: Warner Losh Date: Thu, 27 Jan 2011 14:53:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> <4D41C29A.5020100@bsdimp.com> In-Reply-To: <4D41C29A.5020100@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101271453.10305.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 27 Jan 2011 14:56:18 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , Ken Smith , Alexander Motin , "Robert N. M. Watson" , svn-src-projects@freebsd.org Subject: Re: svn commit: r217828 - projects/graid/head/sys/geom/raid X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:56:20 -0000 On Thursday, January 27, 2011 2:08:10 pm Warner Losh wrote: > On 01/26/2011 08:45, Robert N. M. Watson wrote: > > On 26 Jan 2011, at 15:42, John Baldwin wrote: > > > >> On Wednesday, January 26, 2011 10:06:47 am Ken Smith wrote: > >>> On Wed, 2011-01-26 at 11:45 +0200, Alexander Motin wrote: > >>>> Those who want maximum robustness should use dedicated > >>>> drive on the most trivial dedicated controller to make dumping reliable. > >>>> If we are going above that - there are always some compromises. > >>> Please remember this statement when I change dumpdev from "AUTO" > >>> to "NO" in /etc/defaults/rc.conf shortly after branching stable/9. :-) > >> No, I still think this is the wrong answer. Kernel dumps are not inherently > >> unreliable to the point that we should not enable them by default. However, > >> turning dumps off is a good way to prevent developers from debugging non- > >> trivial bugs that are only triggered under real-world workloads. > >> > >> I think we should strive to make our dumps as reliable as possible, but > >> nothing in our system is perfect (hence bugs), and if we are going to require > >> absolute perfection for kernel dumps before enabling them by default then we > >> might as well not ship anything at all as I can _ensure_ you the rest of the > >> system we ship is _not_ absolutely perfect. > > I think the real constraint on shipping with dumps enabled remains a disk space consideration. If you have a problem triggering a kernel bug, you're going to generate quite a few crash dumps in short order, and for many users, that result is not good. But the answer there may be better savecore behaviour: perhaps we should keep the last (n) (where n is small -- perhaps 2) dumps by default, with a way to mark dumps that should be saved longer. minidumps have made the world better in some ways, I can't help wonder whether that could be refined further... > > I don't suppose there's a way that savecore could be hacked to convert a > 'full' dump into a 'mini' dump? Well, minidumps are already enabled by default so I think that is less important. Probably savecore's policy needs to change so that it saves the most recent N dumps rather than the oldest N dumps and that something like minfree needs to be enabled by default. -- John Baldwin