svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib
sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf
rwatson at FreeBSD.org
Thu Sep 10 15:43:35 UTC 2009
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
University of Cambridge
More information about the svn-src-stable-8