From owner-svn-src-head@FreeBSD.ORG Wed Apr 2 16:48:13 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91524D56; Wed, 2 Apr 2014 16:48:13 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A568A50; Wed, 2 Apr 2014 16:48:13 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 975C7BC12; Wed, 2 Apr 2014 16:48:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 975C7BC12 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 2 Apr 2014 12:48:08 -0400 From: Glen Barber To: Brooks Davis Subject: Re: svn commit: r264027 - in head: release share/man/man7 Message-ID: <20140402164808.GJ14379@glenbarber.us> References: <201404012241.s31MfRW6020684@svn.freebsd.org> <20140402154022.GA70867@lor.one-eyed-alien.net> <20140402155134.GG14379@glenbarber.us> <533C32F5.9050809@mail.lifanov.com> <20140402160650.GH14379@glenbarber.us> <533C3992.9030203@mail.lifanov.com> <20140402163350.GI14379@glenbarber.us> <20140402164128.GB70867@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tKy6e3LXpfmanBFM" Content-Disposition: inline In-Reply-To: <20140402164128.GB70867@lor.one-eyed-alien.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Nikolai Lifanov X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:48:13 -0000 --tKy6e3LXpfmanBFM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 11:41:29AM -0500, Brooks Davis wrote: > On Wed, Apr 02, 2014 at 12:33:50PM -0400, Glen Barber wrote: > > On Wed, Apr 02, 2014 at 12:23:46PM -0400, Nikolai Lifanov wrote: > > > On 04/02/14 12:06, Glen Barber wrote: > > > > On Wed, Apr 02, 2014 at 11:55:33AM -0400, Nikolai Lifanov wrote: > > > >> On 04/02/14 11:51, Glen Barber wrote: > > > >>> On Wed, Apr 02, 2014 at 10:40:22AM -0500, Brooks Davis wrote: > > > >>>> On Tue, Apr 01, 2014 at 10:41:27PM +0000, Glen Barber wrote: > > > >>>>> Author: gjb > > > >>>>> Date: Tue Apr 1 22:41:26 2014 > > > >>>>> New Revision: 264027 > > > >>>>> URL: http://svnweb.freebsd.org/changeset/base/264027 > > > >>>>> > > > >>>>> Log: > > > >>>>> Add a new release build variable, WITH_COMPRESSED_IMAGES. > > > >>>>> =20 > > > >>>>> When set to a non-empty value, the installation medium is > > > >>>>> compressed with gzip(1) as part of the 'install' target in > > > >>>>> the release/ directory. > > > >>>>> =20 > > > >>>>> With gzip(1) compression, downloadable image are reduced in > > > >>>>> size quite significantly. Build test against head@263927 > > > >>>>> shows the following: > > > >>>>> =20 > > > >>>>> bootonly.iso: 64% smaller > > > >>>>> disc1.iso: 44% smaller > > > >>>>> memstick.img: 47% smaller > > > >>>>> mini-memstick.img: 65% smaller > > > >>>>> dvd1.iso: untested > > > >>>>> =20 > > > >>>>> This option is off by default, I would eventually like to > > > >>>>> turn it on by default, and remove the '-k' flag to gzip(1) > > > >>>>> so only compressed images are published on FTP. > > > >>>> > > > >>>> I'd recommend testing xz compression as well. With UFS images o= f a full > > > >>>> world the savings vs gzip are significant (more than 30% IIRC, b= ut it's > > > >>>> need more than a year since I checked so I'm a bit unsure of the= exact > > > >>>> numbers). > > > >>>> > > > >>> > > > >>> delphij also brought this up. > > > >>> > > > >>> I have concerns with xz(1), since there was mention in IRC that W= indows > > > >>> users may have problems decompressing xz-compressed images. So, = gzip(1) > > > >>> is used because it seems to be the more commonly-supported archive > > > >>> mechanisms. > > > >>> > > > >>> The benefit of xz(1) over gzip(1) was only 50M-ish. > > > >>> > > > >>> -rw-r--r-- 1 root wheel 601M Mar 28 20:18 disc1.iso > > > >>> -rw-r--r-- 1 root wheel 381M Mar 28 20:18 disc1.iso.bz2 > > > >>> -rw-r--r-- 1 root wheel 392M Mar 28 20:18 disc1.iso.gz > > > >>> -rw-r--r-- 1 root wheel 348M Mar 28 20:18 disc1.iso.xz > > > >>> > > > >>> Glen > > > >>> > > > >> > > > >> How about 7zip (Windows program, not file format)? What would a Wi= ndows > > > >> user use that can decompress gzip and not xz? It was a problem aro= und > > > >> ~2007, but xz support is no longer rare or exotic. > > > >> > > > >=20 > > > > I don't know, to be honest. I have no Windows machines to test, so > > > > I can only go by what I am told. > > > >=20 > > > > Glen > > > >=20 > > >=20 > > > I just verified it with 7zip for Windows version 9.22. It extracts > > > .tar.xz archives and decompresses .xz images. > > >=20 > >=20 > > Great, thank you for confirming. > >=20 > > So, the question I have now is, considering the time it takes to > > compress the image with xz(1) compared to gzip(1), is that worth saving > > the 50MB space? > >=20 > > I do not object to using xz(1), but the compression time difference was > > quite significant. (I do not have numbers off-hand, but can run the > > compression again.) >=20 > xz is quite slow, but who cares if it's something we do once for the > benefit of many. One thing I did do in my build system is use pxz from > ports. It speeds things up quite a bit on many-core machines with lots > of ram. >=20 Based on the feedback received on this, I think it's clear that xz(1) is the better choice, so I'll make the relevant changes shortly. I was more worried about Windows users needing to go through pain to decompress the images, which seems like a non-issue now. Thanks Brooks and Nikolai for the input. Glen --tKy6e3LXpfmanBFM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPD9IAAoJELls3eqvi17Q7m0P/RUHD/s6/knz2Bykl+cC6eQY ivfLgZAEN2ShFVp31dSOnE+3E3QJyQ4rorq9oLdYXwPEvqYVDLCDBqYY0ceIHYGy C76S+oSUR0Ox80zVqaW/hM6A37roTHLOa9+VXIf7W+jjSjBpzDmfvqNGMJzuarFi kp6mKdkg1W3J8v5Ivn/9AGwTQ/9acdVjC32KwYqLA9oKmJGE2bnKxd90wlnJ0DUs wVZPU5P0TuX0yDLck/vW25V6BCe8Nr2szKNjkkJzud5lHQRRL/DwpWuYUmX23h6m AtA5srXM4PmWBTutxl4RfNCgQIl/9udrpLcL1Afemm1vnSKI+x21Ut5/inbnp2JH 9rrQYUnpv3Ydoo/6aJu83lRnilp2xXiWFyP3V1Lq0RfHUfAujbw8HLNLSoEx/tGL Nv69DEDLDraVmuYdOJhft2RKuIl3qbwbLhDxPftPp5HgiPF/uMNKC1cNySwmwBmI YOEq4+ftfXtUwRHH2pY7NGIk8ddwJfmBCStIrjxWI8lLMFeYcBJIOCA9raKYBflX C0Fd9WDLW6GbYM+PGHjnLrzpoUae9FIT1ss8HVhY5zS+sNEErzPGrDTa10NYeKuP NMaJPVY02nMBb/kLfYGOz16sZZLogod1xxYPhSpUmGnutkdYbOD5eH529Gr2tmHO tIAt9FWuoJa9u5c3knEw =sPvA -----END PGP SIGNATURE----- --tKy6e3LXpfmanBFM--