From owner-svn-src-all@freebsd.org Sat Apr 15 08:39:56 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFC31D3C9F0; Sat, 15 Apr 2017 08:39:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FA9B6DB; Sat, 15 Apr 2017 08:39:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1czJFI-000LrG-RZ; Sat, 15 Apr 2017 11:39:52 +0300 Date: Sat, 15 Apr 2017 11:39:52 +0300 From: Slawa Olhovchenkov To: Mark Johnston Cc: Xin LI , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Ngie Cooper , Alan Somers Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <20170415083952.GA83631@zxy.spb.ru> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 08:39:57 -0000 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?