Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Denys Vlasenko
On Tuesday 16 October 2007 14:31, Andreas Schwab wrote:
> Denys Vlasenko <[EMAIL PROTECTED]> writes:
> 
> > I'm with Al on this. 50 Mb for decompression?
> > Embedded and small device folks will not love this, I'm sure.
> 
> How often do you unpack the kernel sources on an embedded device? :)

Oops. I goofed up, I somehow thought we were talking about kernel _images_
being compressed. :(
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Jan Engelhardt

On Oct 16 2007 14:19, Denys Vlasenko wrote:
>Sizes in Kb again:
>
>32392 linux-2.6.16.17.tar.7z
>33520 linux-2.6.16.17.tar.lzma
>
>P.S. sorting files by extension in tarball generally helps, but in case
>of Linux kernel, they are all C code anyway, so no measurable gain there.

Extension is not all so interesting because, as you point out,
most of it is C code, and .h files are mostly like .c in that they
have structs and function prototype keywords. But sorting by
name buys:

-rw-r--r--  1 jengelh users 45477128 Oct 12 18:47 linux-2.6.23.1.orig.tar.bz2
-rw-r--r--  1 jengelh users 45560647 Oct 16 16:18 linux-2.6.23.1.new.tar.bz2

(actually, `find "$@" -print0 | sort -z | tar -T- --null --no-r --owner=root
--group=root -cvjf "$output";` was used)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Andreas Schwab
Denys Vlasenko <[EMAIL PROTECTED]> writes:

> I'm with Al on this. 50 Mb for decompression?
> Embedded and small device folks will not love this, I'm sure.

How often do you unpack the kernel sources on an embedded device? :)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Denys Vlasenko
On Sunday 14 October 2007 21:58, Justin Piszcz wrote:
> 
> On Sun, 14 Oct 2007, Al Viro wrote:
> 
> > On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
> >> (Obviously we shall pick .7z)
> >
> > The hell it is.  Take a look at memory footprint of those suckers...
> 
> For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
> For decompression, 50-70 MiB.

I'm with Al on this. 50 Mb for decompression?
Embedded and small device folks will not love this, I'm sure.
*Maybe* we can use lzma. Seems to use 8Mb on decompression:

  PID   VSZ*VSZRW   RSS (SHR) DIRTY (SHR) STACK COMMAND
30474 10708  8604  8760   392  8360 0 8 lzmacat pld-th-x86_64.tar.lzma

(pld-th-x86_64.tar.lzma is a random 40Mb .lzma file I found on the net)

Sizes in Kb again:

32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma

P.S. sorting files by extension in tarball generally helps, but in case
of Linux kernel, they are all C code anyway, so no measurable gain there.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Denys Vlasenko
On Sunday 14 October 2007 21:58, Justin Piszcz wrote:
 
 On Sun, 14 Oct 2007, Al Viro wrote:
 
  On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
  (Obviously we shall pick .7z)
 
  The hell it is.  Take a look at memory footprint of those suckers...
 
 For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
 For decompression, 50-70 MiB.

I'm with Al on this. 50 Mb for decompression?
Embedded and small device folks will not love this, I'm sure.
*Maybe* we can use lzma. Seems to use 8Mb on decompression:

  PID   VSZ*VSZRW   RSS (SHR) DIRTY (SHR) STACK COMMAND
30474 10708  8604  8760   392  8360 0 8 lzmacat pld-th-x86_64.tar.lzma

(pld-th-x86_64.tar.lzma is a random 40Mb .lzma file I found on the net)

Sizes in Kb again:

32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma

P.S. sorting files by extension in tarball generally helps, but in case
of Linux kernel, they are all C code anyway, so no measurable gain there.
--
vda
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Andreas Schwab
Denys Vlasenko [EMAIL PROTECTED] writes:

 I'm with Al on this. 50 Mb for decompression?
 Embedded and small device folks will not love this, I'm sure.

How often do you unpack the kernel sources on an embedded device? :)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Jan Engelhardt

On Oct 16 2007 14:19, Denys Vlasenko wrote:
Sizes in Kb again:

32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma

P.S. sorting files by extension in tarball generally helps, but in case
of Linux kernel, they are all C code anyway, so no measurable gain there.

Extension is not all so interesting because, as you point out,
most of it is C code, and .h files are mostly like .c in that they
have structs and function prototype keywords. But sorting by
name buys:

-rw-r--r--  1 jengelh users 45477128 Oct 12 18:47 linux-2.6.23.1.orig.tar.bz2
-rw-r--r--  1 jengelh users 45560647 Oct 16 16:18 linux-2.6.23.1.new.tar.bz2

(actually, `find $@ -print0 | sort -z | tar -T- --null --no-r --owner=root
--group=root -cvjf $output;` was used)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-16 Thread Denys Vlasenko
On Tuesday 16 October 2007 14:31, Andreas Schwab wrote:
 Denys Vlasenko [EMAIL PROTECTED] writes:
 
  I'm with Al on this. 50 Mb for decompression?
  Embedded and small device folks will not love this, I'm sure.
 
 How often do you unpack the kernel sources on an embedded device? :)

Oops. I goofed up, I somehow thought we were talking about kernel _images_
being compressed. :(
--
vda
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 16:58, Justin Piszcz wrote:


compress:
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z


Just how you can utilize a CPU to 141% remains a mystery..
[ to be noted this is sqrt(2)*100 ]



It uses 2 cores (multi-thread/multi-core), I believe the author of 7z (I 
asked him about this before) said the compression algorithm can use 
1.8-2.2 cpus.


Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 16:58, Justin Piszcz wrote:
>
> compress:
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z

Just how you can utilize a CPU to 141% remains a mystery..
[ to be noted this is sqrt(2)*100 ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Al Viro wrote:


On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:

(Obviously we shall pick .7z)


The hell it is.  Take a look at memory footprint of those suckers...



For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
For decompression, 50-70 MiB.

Each have their pros/cons but nothing can compress the kernel any further 
than 7z, supports stdin/stdout and also has a native windows port.  I used 
to strictly use bzip2 for backups and such but if I can pick off an 
additional 20-30% more than bzip2 for my backups which I will not use often,
7zip seems to be the winner for space savings and possibly for 
bandwidth/cost savings..


compress:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z

decompress:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11927 war   20   0 71256  66m 1536 R   88  2.0   0:04.07 7z

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Al Viro
On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
> (Obviously we shall pick .7z)

The hell it is.  Take a look at memory footprint of those suckers...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 15:53, Justin Piszcz wrote:


What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?

$ apt-cache search lrzip
$

I tried most of the main ones in the standard testing distribution within
Debian.


Debian is not a solution to everything.

http://ck.kolivas.org/apps/lrzip/



$ lrzip -L 9 linux-2.6.16.17.tar
Failed to open streams in rzip_fd
Fatal error - exiting

$ lrzip linux-2.6.16.17.tar -o linux-2.6.16.17.tar.lrz
Failed to open streams in rzip_fd
Fatal error - exiting

$ lrzip -l -L 9 linux-2.6.16.17.tar
Bus error

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
22176 abc   20   0 2197m 156m  75m R   93  4.8   0:09.17 lrzip

It must grow to 3.0GB and die (this is on an x86 host)..

$ lrzip -w 1 -l -L 9 linux-2.6.16.17.tar
linux-2.6.16.17.tar - compression ratio 3.127

$ du -sh *lrz
72M linux-2.6.16.17.tar.lrz

$ lrzip -w 10 -l -L 9 linux-2.6.16.17.tar
linux-2.6.16.17.tar - compression ratio 3.380
$ du -sh *lrz
67M linux-2.6.16.17.tar.lrz

Does not seem to come close unless I am doing something wrong.

Also, 7z can compress/decompress on stdin and it is multi-threaded (uses 
1.8-2.2 CPU/cores).



note that lrzip cannot operate on stdin/stdout


Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 15:53, Justin Piszcz wrote:
>>
>> What's with all these odd formats, and where is .zip? :)
>> Somehow... have you tried lrzip?
> $ apt-cache search lrzip
> $
>
> I tried most of the main ones in the standard testing distribution within
> Debian.

Debian is not a solution to everything.

http://ck.kolivas.org/apps/lrzip/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 15:34, Justin Piszcz wrote:


It turns out the one I did not test, was actually the best:

Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar


What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?

$ apt-cache search lrzip
$

I tried most of the main ones in the standard testing distribution within 
Debian.



Furthermore, if the files in the .tar archive were actually sorted..
(Obviously we shall pick .7z)



Ah, how did I miss zip? :)

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49940 linux-2.6.16.17.tar.zip
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar

$ du -sh * | sort -n
32M linux-2.6.16.17.tar.7z
33M linux-2.6.16.17.tar.lzma
33M linux-2.6.16.17.tar.rar
37M linux-2.6.16.17.tar.rz
39M linux-2.6.16.17.tar.bicom
39M linux-2.6.16.17.tar.bz
39M linux-2.6.16.17.tar.bz2
39M linux-2.6.16.17.tar.szip
40M linux-2.6.16.17.tar.sit
47M linux-2.6.16.17.tar.lha
49M linux-2.6.16.17.tar.zip
49M linux-2.6.16.17.tar.dzip
49M linux-2.6.16.17.tar.gz
50M linux-2.6.16.17.tar.arj
56M linux-2.6.16.17.tar.lzo
57M linux-2.6.16.17.tar.F
79M linux-2.6.16.17.tar.Z
92M linux-2.6.16.17.tar.zoo
99M linux-2.6.16.17.tar.arc
223M linux-2.6.16.17.tar

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 15:34, Justin Piszcz wrote:
>
> It turns out the one I did not test, was actually the best:
>
> Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar
>
> $ du -sk * | sort -n
> 32392 linux-2.6.16.17.tar.7z
> 33520 linux-2.6.16.17.tar.lzma
> 33760 linux-2.6.16.17.tar.rar
> 38064 linux-2.6.16.17.tar.rz
> 39472 linux-2.6.16.17.tar.szip
> 39520 linux-2.6.16.17.tar.bz
> 39936 linux-2.6.16.17.tar.bz2
> 4 linux-2.6.16.17.tar.bicom
> 40656 linux-2.6.16.17.tar.sit
> 47664 linux-2.6.16.17.tar.lha
> 49968 linux-2.6.16.17.tar.dzip
> 5 linux-2.6.16.17.tar.gz
> 51344 linux-2.6.16.17.tar.arj
> 57552 linux-2.6.16.17.tar.lzo
> 57984 linux-2.6.16.17.tar.F
> 81136 linux-2.6.16.17.tar.Z
> 94544 linux-2.6.16.17.tar.zoo
> 101216 linux-2.6.16.17.tar.arc
> 228608 linux-2.6.16.17.tar

What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?
Furthermore, if the files in the .tar archive were actually sorted..
(Obviously we shall pick .7z)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz

It turns out the one I did not test, was actually the best:

Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar

$ du -sh * | sort -n
32M linux-2.6.16.17.tar.7z
33M linux-2.6.16.17.tar.lzma
33M linux-2.6.16.17.tar.rar
37M linux-2.6.16.17.tar.rz
39M linux-2.6.16.17.tar.bicom
39M linux-2.6.16.17.tar.bz
39M linux-2.6.16.17.tar.bz2
39M linux-2.6.16.17.tar.szip
40M linux-2.6.16.17.tar.sit
47M linux-2.6.16.17.tar.lha
49M linux-2.6.16.17.tar.dzip
49M linux-2.6.16.17.tar.gz
50M linux-2.6.16.17.tar.arj
56M linux-2.6.16.17.tar.lzo
57M linux-2.6.16.17.tar.F
79M linux-2.6.16.17.tar.Z
92M linux-2.6.16.17.tar.zoo
99M linux-2.6.16.17.tar.arc
223M linux-2.6.16.17.tar



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


In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz

It turns out the one I did not test, was actually the best:

Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar

$ du -sh * | sort -n
32M linux-2.6.16.17.tar.7z
33M linux-2.6.16.17.tar.lzma
33M linux-2.6.16.17.tar.rar
37M linux-2.6.16.17.tar.rz
39M linux-2.6.16.17.tar.bicom
39M linux-2.6.16.17.tar.bz
39M linux-2.6.16.17.tar.bz2
39M linux-2.6.16.17.tar.szip
40M linux-2.6.16.17.tar.sit
47M linux-2.6.16.17.tar.lha
49M linux-2.6.16.17.tar.dzip
49M linux-2.6.16.17.tar.gz
50M linux-2.6.16.17.tar.arj
56M linux-2.6.16.17.tar.lzo
57M linux-2.6.16.17.tar.F
79M linux-2.6.16.17.tar.Z
92M linux-2.6.16.17.tar.zoo
99M linux-2.6.16.17.tar.arc
223M linux-2.6.16.17.tar



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 15:34, Justin Piszcz wrote:

 It turns out the one I did not test, was actually the best:

 Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar

 $ du -sk * | sort -n
 32392 linux-2.6.16.17.tar.7z
 33520 linux-2.6.16.17.tar.lzma
 33760 linux-2.6.16.17.tar.rar
 38064 linux-2.6.16.17.tar.rz
 39472 linux-2.6.16.17.tar.szip
 39520 linux-2.6.16.17.tar.bz
 39936 linux-2.6.16.17.tar.bz2
 4 linux-2.6.16.17.tar.bicom
 40656 linux-2.6.16.17.tar.sit
 47664 linux-2.6.16.17.tar.lha
 49968 linux-2.6.16.17.tar.dzip
 5 linux-2.6.16.17.tar.gz
 51344 linux-2.6.16.17.tar.arj
 57552 linux-2.6.16.17.tar.lzo
 57984 linux-2.6.16.17.tar.F
 81136 linux-2.6.16.17.tar.Z
 94544 linux-2.6.16.17.tar.zoo
 101216 linux-2.6.16.17.tar.arc
 228608 linux-2.6.16.17.tar

What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?
Furthermore, if the files in the .tar archive were actually sorted..
(Obviously we shall pick .7z)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 15:34, Justin Piszcz wrote:


It turns out the one I did not test, was actually the best:

Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar


What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?

$ apt-cache search lrzip
$

I tried most of the main ones in the standard testing distribution within 
Debian.



Furthermore, if the files in the .tar archive were actually sorted..
(Obviously we shall pick .7z)



Ah, how did I miss zip? :)

$ du -sk * | sort -n
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
33760 linux-2.6.16.17.tar.rar
38064 linux-2.6.16.17.tar.rz
39472 linux-2.6.16.17.tar.szip
39520 linux-2.6.16.17.tar.bz
39936 linux-2.6.16.17.tar.bz2
4 linux-2.6.16.17.tar.bicom
40656 linux-2.6.16.17.tar.sit
47664 linux-2.6.16.17.tar.lha
49940 linux-2.6.16.17.tar.zip
49968 linux-2.6.16.17.tar.dzip
5 linux-2.6.16.17.tar.gz
51344 linux-2.6.16.17.tar.arj
57552 linux-2.6.16.17.tar.lzo
57984 linux-2.6.16.17.tar.F
81136 linux-2.6.16.17.tar.Z
94544 linux-2.6.16.17.tar.zoo
101216 linux-2.6.16.17.tar.arc
228608 linux-2.6.16.17.tar

$ du -sh * | sort -n
32M linux-2.6.16.17.tar.7z
33M linux-2.6.16.17.tar.lzma
33M linux-2.6.16.17.tar.rar
37M linux-2.6.16.17.tar.rz
39M linux-2.6.16.17.tar.bicom
39M linux-2.6.16.17.tar.bz
39M linux-2.6.16.17.tar.bz2
39M linux-2.6.16.17.tar.szip
40M linux-2.6.16.17.tar.sit
47M linux-2.6.16.17.tar.lha
49M linux-2.6.16.17.tar.zip
49M linux-2.6.16.17.tar.dzip
49M linux-2.6.16.17.tar.gz
50M linux-2.6.16.17.tar.arj
56M linux-2.6.16.17.tar.lzo
57M linux-2.6.16.17.tar.F
79M linux-2.6.16.17.tar.Z
92M linux-2.6.16.17.tar.zoo
99M linux-2.6.16.17.tar.arc
223M linux-2.6.16.17.tar

Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 15:53, Justin Piszcz wrote:

 What's with all these odd formats, and where is .zip? :)
 Somehow... have you tried lrzip?
 $ apt-cache search lrzip
 $

 I tried most of the main ones in the standard testing distribution within
 Debian.

Debian is not a solution to everything.

http://ck.kolivas.org/apps/lrzip/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 15:53, Justin Piszcz wrote:


What's with all these odd formats, and where is .zip? :)
Somehow... have you tried lrzip?

$ apt-cache search lrzip
$

I tried most of the main ones in the standard testing distribution within
Debian.


Debian is not a solution to everything.

http://ck.kolivas.org/apps/lrzip/



$ lrzip -L 9 linux-2.6.16.17.tar
Failed to open streams in rzip_fd
Fatal error - exiting

$ lrzip linux-2.6.16.17.tar -o linux-2.6.16.17.tar.lrz
Failed to open streams in rzip_fd
Fatal error - exiting

$ lrzip -l -L 9 linux-2.6.16.17.tar
Bus error

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
22176 abc   20   0 2197m 156m  75m R   93  4.8   0:09.17 lrzip

It must grow to 3.0GB and die (this is on an x86 host)..

$ lrzip -w 1 -l -L 9 linux-2.6.16.17.tar
linux-2.6.16.17.tar - compression ratio 3.127

$ du -sh *lrz
72M linux-2.6.16.17.tar.lrz

$ lrzip -w 10 -l -L 9 linux-2.6.16.17.tar
linux-2.6.16.17.tar - compression ratio 3.380
$ du -sh *lrz
67M linux-2.6.16.17.tar.lrz

Does not seem to come close unless I am doing something wrong.

Also, 7z can compress/decompress on stdin and it is multi-threaded (uses 
1.8-2.2 CPU/cores).



note that lrzip cannot operate on stdin/stdout


Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Al Viro
On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
 (Obviously we shall pick .7z)

The hell it is.  Take a look at memory footprint of those suckers...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Al Viro wrote:


On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:

(Obviously we shall pick .7z)


The hell it is.  Take a look at memory footprint of those suckers...



For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
For decompression, 50-70 MiB.

Each have their pros/cons but nothing can compress the kernel any further 
than 7z, supports stdin/stdout and also has a native windows port.  I used 
to strictly use bzip2 for backups and such but if I can pick off an 
additional 20-30% more than bzip2 for my backups which I will not use often,
7zip seems to be the winner for space savings and possibly for 
bandwidth/cost savings..


compress:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z

decompress:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11927 war   20   0 71256  66m 1536 R   88  2.0   0:04.07 7z

Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Jan Engelhardt

On Oct 14 2007 16:58, Justin Piszcz wrote:

 compress:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z

Just how you can utilize a CPU to 141% remains a mystery..
[ to be noted this is sqrt(2)*100 ]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: In response to kernel compression e-mail a few months ago.

2007-10-14 Thread Justin Piszcz



On Sun, 14 Oct 2007, Jan Engelhardt wrote:



On Oct 14 2007 16:58, Justin Piszcz wrote:


compress:
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10544 war   20   0  700m 681m 1632 S  141 20.7   1:41.46 7z


Just how you can utilize a CPU to 141% remains a mystery..
[ to be noted this is sqrt(2)*100 ]



It uses 2 cores (multi-thread/multi-core), I believe the author of 7z (I 
asked him about this before) said the compression algorithm can use 
1.8-2.2 cpus.


Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/