From owner-svn-src-all@freebsd.org Sat Apr 15 16:29:05 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 B1CFBD3F440; Sat, 15 Apr 2017 16:29:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E419AAE; Sat, 15 Apr 2017 16:29:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id i5so18850881pfc.3; Sat, 15 Apr 2017 09:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YhlFxMVUtSS8ZA3iuignQGEkCC7tEVx1WCCxemmcv0s=; b=hUTCK1TWX4aadTsDkOE8FOA72op7m0dmm6dE7moYdl7FlhqC4FTmw451/NGa54HVe4 zI657lQNHrWhE1QiZsxU96oPRPCKucEFiwtAMpwcXoJUkPZb5ElhO6INJj2JErr1qmXN vY1qyNSKFz4M9X70RFnENL8pllW6GCFNoWrTpe1vUjIUnJmVBRr1eRuwL3gQpCX7Uyiv v4MTsIyrHY/5YK92TQBoe5vhBjU5HUOZAkMrMnzDlTiQJN4oPFiHuA9KiC50ePW9ZWqf k7dEnbHfNQefYQ63Yp5+91WAtFnchqdc2QCdpgG922UIc3CYfwA2/gP/NSXzweuiK5Ta X06A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=YhlFxMVUtSS8ZA3iuignQGEkCC7tEVx1WCCxemmcv0s=; b=mOMQ6GtWcLtbvAAVnOgLcmOakFMZf1dQBIL+A+hC9sS+q8UeQVdJArHwsTwUrmyUbZ 3+64+HMUdcabnYrn1GoAG1MrkaFL7wTyYwkywm73sNpSXBNcE2A+6Dd97NkOLG3pf58F FW2S9hBJjUnI9M2ApUKnS8BzbrXD2FOWT66C6sOoO/E7CpQrDJpkcKcf3b6pXllKg7lm 2U0seLkN4z5z++JqO5+KbxiWGzSiMWoOce6AtwUA6agTL3hZ/tXBhalVJwNSGnoHbNCv ENTQqqRrwjuZRHeibbxRzsh7Hj5Wh59ZNgSpJiNVvroE3ifgrmkaqgLV/4pnntr+R5kx lsKg== X-Gm-Message-State: AN3rC/76sCgywPTXbLObcP9wQ2gV304lWoUw3JZquJ7dFfqw6XHcmEU7 1t3uh7udk+Ictw== X-Received: by 10.99.189.2 with SMTP id a2mr3449645pgf.85.1492273745123; Sat, 15 Apr 2017 09:29:05 -0700 (PDT) Received: from raichu ([2604:4080:1102:0:ca60:ff:fe9d:3963]) by smtp.gmail.com with ESMTPSA id 21sm9340692pfl.129.2017.04.15.09.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 09:29:04 -0700 (PDT) Sender: Mark Johnston Date: Sat, 15 Apr 2017 09:29:02 -0700 From: Mark Johnston To: Slawa Olhovchenkov 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: <20170415162902.GB89653@raichu> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> <20170415083952.GA83631@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170415083952.GA83631@zxy.spb.ru> User-Agent: Mutt/1.8.0 (2017-02-23) 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 16:29:05 -0000 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.