Date: Thu, 12 Jul 2018 14:35:57 -0400 From: Mark Johnston <markj@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Alexander Leidinger <Alexander@leidinger.net>, hackers@freebsd.org Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? Message-ID: <20180712183557.GD15892@raichu> In-Reply-To: <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 12, 2018 at 09:09:02AM -0700, John Baldwin wrote: > On 7/12/18 7:31 AM, Mark Johnston 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) > >> > >> 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. > > Yes, here's the patch for 2 which has been tested. 4) is pretty hard > to do in practice as you have to basically decompress into RAM when > reading the core to do anything useful as opposed to a format that > only compressed certain parts (e.g. if the page tables were not > compressed only the payload in a minidump, and if it were compressed > on some kind of block boundaries so that you could locate a given > block and decompress it when reading specific data). Coming up with > such a format would be more useful but requires more work. That patch looks ok to me, FWIW. As I pointed out, it's easy enough to just disable crashinfo if one doesn't want the extraction to take place.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180712183557.GD15892>