svn commit: r264027 - in head: release share/man/man7

[Glen Barber]

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.
> > > >>>>>   
> > > >>>>>   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.
> > > >>>>>   
> > > >>>>>   With gzip(1) compression, downloadable image are reduced in
> > > >>>>>   size quite significantly.  Build test against head at 263927
> > > >>>>>   shows the following:
> > > >>>>>   
> > > >>>>>    bootonly.iso:		64% smaller
> > > >>>>>    disc1.iso:		44% smaller
> > > >>>>>    memstick.img:		47% smaller
> > > >>>>>    mini-memstick.img:	65% smaller
> > > >>>>>    dvd1.iso:		untested
> > > >>>>>   
> > > >>>>>   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 of a full
> > > >>>> world the savings vs gzip are significant (more than 30% IIRC, but 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 Windows
> > > >>> 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 Windows
> > > >> user use that can decompress gzip and not xz? It was a problem around
> > > >> ~2007, but xz support is no longer rare or exotic.
> > > >>
> > > > 
> > > > I don't know, to be honest.  I have no Windows machines to test, so
> > > > I can only go by what I am told.
> > > > 
> > > > Glen
> > > > 
> > > 
> > > I just verified it with 7zip for Windows version 9.22. It extracts
> > > .tar.xz archives and decompresses .xz images.
> > > 
> > 
> > Great, thank you for confirming.
> > 
> > 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?
> > 
> > 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.)
> 
> 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.
> 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20140402/a8863358/attachment-0001.sig>