From owner-svn-src-projects@FreeBSD.ORG Thu Jan 27 19:14:17 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 D36181065670; Thu, 27 Jan 2011 19:14:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 709E68FC0A; Thu, 27 Jan 2011 19:14:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p0RJ8AYw079074; Thu, 27 Jan 2011 12:08:10 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D41C29A.5020100@bsdimp.com> Date: Thu, 27 Jan 2011 12:08:10 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <4D3FED31.8040304@FreeBSD.org> <1296054407.19051.5.camel@bauer.cse.buffalo.edu> <201101261042.38218.jhb@freebsd.org> <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> In-Reply-To: <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , John Baldwin , Ken Smith , Alexander Motin , 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:14:17 -0000 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? Warner