On Sep 10, 2009, at 5:43 PM, Robert Watson wrote:
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
I agree with that; it would (!) help the bugbusting team in gathering
required information. If there is an way to automate crashdumps and
proper reporting and stick that in /var/crash/crash.$date or something
and tell people that
they can report their problems on the bugs list where needed, we have
information upfront. I still remember the time where we had to chase
people to get this information, sometimes never being able to properly
get the information.
If it is there by default, it will help.
Please consider keeping it enabled..
Thanks,
Remko
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
