Date: Thu, 12 Jul 2018 10:31:18 -0400 From: Mark Johnston <markj@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: hackers@freebsd.org, jhb@freebsd.org Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? Message-ID: <20180712143118.GA15892@raichu> In-Reply-To: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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) > > 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). 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180712143118.GA15892>