crashinfo doesn't support compressed crashdumps - which way forward?

[Alan Somers]

On Thu, Jul 12, 2018 at 8:31 AM, Mark Johnston <markj at freebsd.org> wrote:

> On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote:
> > Hi,
> >
> > the crashinfo script doesn't know how to handle compressed coredumps.
> > What would be acceptable behavior (ordered by my preferrence)?
> >   1) decompress in /var/crash and then proceed normally (already
> > implemented locally)
> >   2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished
> >   3) keep it like it is
> >   4) teach tools to understand compressed dumps (gzip / zstd)
>

I briefly looked into this option, but it's harder than it sounds.  There
are several libraries that would need to be modified, and I think some of
them work by mmap(2)ping the core file rather than by fread(2)ing it.  I
don't know of anyway to mmap a compressed file.


> >
> > Implicitly there is the question what what is the purpose of
> > compressing crashdumps, to have more RAM than space in dumpdev (which
> > is valid in my case), or to save space in /var/crash (which I don't
> > care much about).
>

Compressed crashdumps are also great for systems with slow dumpdevs.  They
greatly speed up the dumping process.


>
> I think jhb has a patch which implements 2).  I do not have strong
> feelings on which is the right way forward, but I mildly prefer 2) to
> 1).  It looks like crashinfo can be disabled in rc.conf, so users who
> are space-constrained in /var/crash can take the additional step of
> setting crashinfo_enable=NO.  FWIW, when I committed the compression
> support, my use-case involved both a small dump device and a small
> /var filesystem.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>