From owner-svn-src-projects@FreeBSD.ORG Wed Jan 26 15:59:22 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 07CD71065672; Wed, 26 Jan 2011 15:59:22 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmailC.acsu.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id C381D8FC1B; Wed, 26 Jan 2011 15:59:21 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E533369408; Wed, 26 Jan 2011 10:59:20 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 25E757A29A; Wed, 26 Jan 2011 10:58:58 -0500 (EST) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 156297A2C9; Wed, 26 Jan 2011 10:58:58 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id 02BB8207B6; Wed, 26 Jan 2011 10:58:58 -0500 (EST) From: Ken Smith To: "Robert N. M. Watson" In-Reply-To: <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> <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hdeUVOr6/zUeD1cQW0wj" Date: Wed, 26 Jan 2011 10:58:57 -0500 Message-ID: <1296057537.19051.32.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: svn-src-projects@freebsd.org, Alexander Motin , src-committers@freebsd.org, Pawel Jakub Dawidek , John Baldwin 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:59:22 -0000 --=-hdeUVOr6/zUeD1cQW0wj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2011-01-26 at 15:45 +0000, Robert N. M. Watson wrote: > On 26 Jan 2011, at 15:42, John Baldwin wrote: >=20 > > 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 reliab= le. > >>> 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 inher= ently=20 > > unreliable to the point that we should not enable them by default. How= ever,=20 > > turning dumps off is a good way to prevent developers from debugging no= n- > > 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 r= equire=20 > > absolute perfection for kernel dumps before enabling them by default th= en we=20 > > might as well not ship anything at all as I can _ensure_ you the rest o= f the=20 > > system we ship is _not_ absolutely perfect. >=20 > 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... >=20 > Robert >=20 This would be the non-smiley version of my thoughts at the moment. I'm not against dumps being enabled but IMHO we're not quite ready yet mostly due to the disk space issues. If that's addressed I'd be less worried about leaving them enabled. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-hdeUVOr6/zUeD1cQW0wj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAk1ARMEACgkQ/G14VSmup/ag5QCeOskf1jiAK1j87jH7N8zKMvvP kUMAnjq/jVoUZ52NRVGYp4PungYZt8UP =fVvl -----END PGP SIGNATURE----- --=-hdeUVOr6/zUeD1cQW0wj--