On Friday, September 24, 2010 6:53:52 pm Peter Jeremy wrote: > [Pruning CC list and re-adding freebsd-arch on the (forlorn) hope that > this thread will move to where it belongs] > > On 2010-Sep-23 07:31:13 -0700, Matthew Jacob <m...@feral.com> wrote: > >It turns out that the big issue here was more the savecore time coming > >back up rather than the time of dumping. > > In my experience, the problem isn't so much the savecore time as the > time to run /usr/bin/crashinfo. Whilst savecore needs to run early > (before anything tramples on the crashdump in swap), the latter could > run at any time. It would seem reasonable to either run crashinfo in > the background or as a batchjob triggered by /etc/rc.d/savecore.
That is probably true and would be fine, yes. > On 2010-Sep-23 18:59:53 +0100, Gavin Atkinson <ga...@freebsd.org> wrote: > >I appreciate the issue about filling partitions is a valid one. Would a > >possible compromise be that on release media, crashinfo(8) or similar will > >default to only keeping the most recent coredump or similar? Given /var > >now defaults to 4GB, Defaulting to keeping a single core is probably > >acceptable. > > savecore already has support for a 'minfree' file to prevent > crashdumps filling the crashdir. Maybe the default install should > include a minfree set to (say) 512MB. The one problem this approach is it implements a FIFO instead of a LIFO. I want the N most recent crashdumps to be saved, not the first N. -- John Baldwin _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
