Date: Sat, 15 Apr 2017 11:39:52 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Mark Johnston <markj@freebsd.org> Cc: Xin LI <delphij@gmail.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <20170415083952.GA83631@zxy.spb.ru> In-Reply-To: <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <CAOtMX2gPHWRGiE9UA5AevZz=cTv_qksAWX0H-xRjDEHp0huCVg@mail.gmail.com> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> <CAGMYy3siQA-%2Brh7RvUoApXA3HJjiiyeb=7d6ZUyBeVJiJjtnhQ@mail.gmail.com> <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 14, 2017 at 03:05:25PM -0700, Mark Johnston wrote: > > And with textdumps available, the benefit > > of having compression is limited because we can request for minidump > > or full dumps only when the textdumps are not good enough for > > diagnosing the kernel bug. > > Sure, but in this case the compression may be vital. > > > > > I don't think security (e.g. leaking information because of the use of > > compression) is a very big concern in this context because in order > > for the potential attacker to read the raw material needs a > > compromised system (unlike an attack from the network, where someone > > who controls the network would have access to the raw material); the > > dump is usually quite large, and measuring downtime would be hard at > > that scale. > > Ok. > > > > > By the way (not meant to bikeshed) if I was to do this I'd prefer > > using lz4 or something that compresses faster than zlib. > > I agree, but I think the existing lz4 implementation in the kernel is > not so well suited to running after a panic. It seems fixable, but > compression speed also isn't hugely important here IMO. On production system this is downtime. For may case, dumped about 32GB (from 256GB RAM). This is take several minutes. Can compression increase this to hour?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170415083952.GA83631>