Date: Wed, 26 Jan 2011 10:58:57 -0500 From: Ken Smith <kensmith@buffalo.edu> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: svn-src-projects@freebsd.org, Alexander Motin <mav@freebsd.org>, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r217828 - projects/graid/head/sys/geom/raid Message-ID: <1296057537.19051.32.camel@bauer.cse.buffalo.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1296057537.19051.32.camel>