svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf

[Robert Watson]

On Thu, 10 Sep 2009, John Baldwin wrote:

>> It has been pointed out to me on the mailing lists that leaving it on for 
>> stable/7 was an oversight, it is off on previous branches.
>>
>> I can understand the motivation for it.  In a data center full of 
>> production machines crash dumps cause reboots to take longer and 
>> potentially cause disk space issues.  In those sorts of environments it's 
>> best if by *default* the crash dumps don't happen and if an admin finds 
>> they need it they turn it on.
>>
>> This is one of those "There is no right answer" things...
>
> Hmm, I thought the crashdumps were a conscious descision as part of another 
> change in 7.x (shipping with debug symbols enabled by default) to try to 
> make it easier to get more useful crash reports from stock kernels.  Having 
> the debug symbols present is probably enough for that though since it is 
> fairly easy to enable crashdumps in rc.conf vs. having to build a new kernel 
> just to get debug symbols.  Should we change the default behavior in 7?

I wonder if we could teach libkvm how to work directly from a crashdump in 
situ in the swap partition?  This would not fix "slower reboot times" but it 
would help a lot with the "running out of disk space" thing.  I see no reason 
at all we shouldn't be logging things like panics/stack traces for every crash 
in our normal logs -- in fact, that was much of the motivation for text dumps 
(and crashinfo too, no doubt): capture critical crash information in a compact 
way that can be e-maile around, etc, without the overhead of multi-gig dumps. 
Teaching libkvm how to work on crash dump partitions would let us avoid having 
the crashdump reside in the file system and help a lot with that problem.

Robert N M Watson
Computer Laboratory
University of Cambridge