linux-kernel - Re: [kernel.org users] XZ Migration discussion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Feb 2010 18:10:08 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Pavel Machek <pavel@....cz>
Cc:	"J.H." <warthog9@...nel.org>,
	"FTPAdmin Kernel.org" <ftpadmin@...nel.org>, users@...nel.org,
	lasse.collin@...aani.org,
	linux-kernel <linux-kernel@...r.kernel.org>, mirrors@...nel.org
Subject: Re: [kernel.org users] XZ Migration discussion

Hi Pavel, all,

On Thu, 11 Feb 2010 21:51:29 +0100, Pavel Machek wrote:
> Hi!
> 
> > Option 1)
> > 
> > Leave gz as the master, and migrate bz2 to xz.  This will happen in
> > stages obviously. with bz2 ultimately being phased out.
> > 
> > 	Migration option 1)
> > 
> > 		All new content would be provided in .bz2 and .xz with
> > 		an ultimate date set that the .bz2 files would stop
> > 		being generated with new content.  This would leave all
> > 		existing content alone and it would not be a migration
> > 		of the current .bz2 files to xz
> 
> I believe this is cleanest. gzip has performance advantages, (...)

I have been investigating this issue and would like to share my
findings as an additional data point for this discussion.

For my testing, I have been using the slowest machine I still have
available here: a Pentium 166 MMX, with 64 MB of memory and a slow hard
disk drive. I've been writing down the duration of each task it took to
boot kernel 2.6.27.45 on this machine. I did this for both .gz and .bz2
formats.

Raw results are as follow (format=min:s):

downloading linux-2.6.27.tar.bz2	  5:01
downloading patch-2.6.27.45.bz2		  0:02
unpacking linux-2.6.27.tar.bz2		  7:28
applying patch-2.6.27.45.bz2		  1:21
----------------------------------------------
total for bz2				 13:52

downloading linux-2.6.27.tar.gz		  6:23
downloading patch-2.6.27.45.gz		  0:02
unpacking linux-2.6.27.tar.gz		  3:20
applying patch-2.6.27.45.gz		  1:10
----------------------------------------------
total for gz				 10:55

So the gz option is unsurprisingly faster, setting up the source tree
takes almost 3 minutes less (-21%).

Then the (common) build and installation times:

building				117:26
installing modules			  0:12
----------------------------------------------
total					117:38

This is a customized kernel, as small as I could do, with almost no
features and the minimal set of drivers. As you can see, the build time
is one order of magnitude greater than the tree setup time. Comparing
the total times from download to install between bz2 and gz:

bz2: 13:52 + 117:38 = 131:30
gz:  10:55 + 117:38 = 128:33

Compared to bz2, gz saves... 2% on the overall time. As a conclusion, I
think we can plain discard the argument "I need .gz because my machine
is slow" from now on. It simply doesn't hold.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/