Date: Fri, 14 Apr 2017 22:37:29 -0700 From: Mark Johnston <markj@freebsd.org> To: rgrimes@freebsd.org Cc: Alan Somers <asomers@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <20170415053729.GA76139@raichu> In-Reply-To: <201704150130.v3F1UHpR009181@pdx.rh.CN85.dnsmgr.net> References: <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> <201704150130.v3F1UHpR009181@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 14, 2017 at 06:30:17PM -0700, Rodney W. Grimes wrote: > > The patch to add compression support is here and should largely still > > work: > > https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_dump.diff > > > > I've been hesitant about pushing it forward: > > - The dump_write* APIs need some simplification after the addition of > > encrypted dump support and support for dumping to 4Kn drives. > > - I'm not sure how encryption should compose with compression. It seems > > intuitively obvious that we should compress before encrypting if the > > compression is to be of any use, but I don't know enough to know > > whether the compression might somehow compromise the effectiveness of > > the encryption. > > > > If anyone has some insight on the second of these two points, I'd > > appreciate hearing it. > > I have a large amount of reworking and modulization of the dump code > incuding intergration of your (markj) compressed dumps. Layer isnt > implemented but is in the plan. I should not of held off on the net > dump code as it got smashed by encrypted dumps, then again by > the libif'ing for all the Intel drives that had been netdump modified. > > Basically now starting over :-( Could you post your patches somewhere? I've been sitting on this (and the netdump patches, for which I have quite a few modifications) for far too long, and would like to finish them and get them in soon. I'll note that the netdump code posted a few years ago had some problems that are fixed in Isilon's version, which I'm working on rebasing on HEAD. In particular, I simplified the driver integration a bit, changed the code to avoid allocating mbufs from UMA after a panic, plumbed a configuration interface through dumpon, and fixed some problems with netdumpd. I'm working on integrating netdump with Isilon's internal infrastructure at the moment. The conversion of em and igb to iflib does complicate things a bit; I haven't yet looked at how hard it would be to support netdump in iflib'ed drivers. > Minidump is an lkm for me, and main dump is almost an lkm for me too. Does "lkm" mean "loadable kernel module"? If so, why?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170415053729.GA76139>