svn commit: r212964 - head/sys/kern

[John Baldwin]

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 <mj at 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 <gavin at 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