Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jan 2011 14:53:10 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Ken Smith <kensmith@buffalo.edu>, Alexander Motin <mav@freebsd.org>, "Robert N. M. Watson" <rwatson@freebsd.org>, svn-src-projects@freebsd.org
Subject:   Re: svn commit: r217828 - projects/graid/head/sys/geom/raid
Message-ID:  <201101271453.10305.jhb@freebsd.org>
In-Reply-To: <4D41C29A.5020100@bsdimp.com>
References:  <201101251534.p0PFY7cF039182@svn.freebsd.org> <7FD27004-581F-4FED-858D-5819562CF111@freebsd.org> <4D41C29A.5020100@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101271453.10305.jhb>