From owner-svn-src-projects@FreeBSD.ORG Wed Jan 26 15:45:36 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 855FA106566B; Wed, 26 Jan 2011 15:45:36 +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 5DB108FC13; Wed, 26 Jan 2011 15:45:36 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 533F346B03; Wed, 26 Jan 2011 10:45:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201101261042.38218.jhb@freebsd.org> Date: Wed, 26 Jan 2011 15:45:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> References: <201101251534.p0PFY7cF039182@svn.freebsd.org> <4D3FED31.8040304@FreeBSD.org> <1296054407.19051.5.camel@bauer.cse.buffalo.edu> <201101261042.38218.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Cc: svn-src-projects@freebsd.org, Alexander Motin , src-committers@freebsd.org, Pawel Jakub Dawidek , Ken Smith 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: Wed, 26 Jan 2011 15:45:36 -0000 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.=20 >>=20 >> Please remember this statement when I change dumpdev from "AUTO" >> to "NO" in /etc/defaults/rc.conf shortly after branching stable/9. = :-) >=20 > No, I still think this is the wrong answer. Kernel dumps are not = inherently=20 > unreliable to the point that we should not enable them by default. = However,=20 > turning dumps off is a good way to prevent developers from debugging = non- > trivial bugs that are only triggered under real-world workloads. >=20 > I think we should strive to make our dumps as reliable as possible, = but=20 > nothing in our system is perfect (hence bugs), and if we are going to = require=20 > absolute perfection for kernel dumps before enabling them by default = then we=20 > might as well not ship anything at all as I can _ensure_ you the rest = of the=20 > 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... Robert=