svn commit: r316938 - head/sbin/savecore

[Mark Johnston]

On Sat, Apr 15, 2017 at 11:39:52AM +0300, Slawa Olhovchenkov wrote:
> 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?

It would have to be tested. The compression also speeds up recovery
somewhat since fewer bytes need to be transferred from the dump device
to a filesystem.

I should also point out that the feature implementation is not closely
tied to the compression algorithm, which could be changed for something
faster later.