svn commit: r217828 - projects/graid/head/sys/geom/raid

[Warner Losh]

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