Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #68260 > unrolled thread

Bug#592519: initramfs-tools: COMPRESS option should be more flexible

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#592519: initramfs-tools: COMPRESS option should be more flexible Rogério Brito <rbrito@ime.usp.br> - 2020-09-25 19:30 +0200
    Bug#592519: initramfs-tools: COMPRESS option should be more flexible Ben Hutchings <ben@decadent.org.uk> - 2020-09-26 02:40 +0200

#68260 — Bug#592519: initramfs-tools: COMPRESS option should be more flexible

Package: initramfs-tools
Version: 0.139
Followup-For: Bug #592519
X-Debbugs-Cc: benh@debian.org, mika@debian.org, debian-kernel@lists.debian.org


Hi.

In a similar vein to what was reported by Roger Shimizu, it takes ages to
compress with xz on an armel system with only 128MB of RAM. By default,
(which is what is used) xz uses level 6 compression and that is what takes a
lot of time to compress.

I switched to gzip and the initrd is quite larger. I just performed some
tests with perf stat running 3 times a lot of commands to compress my
current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than
gzip -9 *and* generating a smaller file as a result.

Here are some results that I gathered. I didn't wait for xz with the default
-6 level to finish...

| compressor           |   time |     size |
|----------------------+--------+----------|
| gzip -9nk            | 69.264 |  5980207 |
| gzip -nk             | 34.468 |  5995619 |
| xz -0k               | 35.280 |  5000752 |
| xz -1k               | 45.351 |  4868388 |
| xz --check=crc32 -1k | 44.902 |  4868384 |
| bzip2 -k             | 51.750 |  5709152 |
| uncompressed         |      0 | 12965376 |

Passing an option to xz (or, in general, to any compressor) would be,
indeed, very nice.

OTOH, on a fast machine, I would like to use something like xz -9e (that is,
maximum compression---probably overkill for not so large files---but with
"extreme" searches for more compression).

Thanks,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [next] | [standalone]

#68262

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2020-09-25 at 14:19 -0300, Rogério Brito wrote:
> Package: initramfs-tools
> Version: 0.139
> Followup-For: Bug #592519
> X-Debbugs-Cc: benh@debian.org, mika@debian.org, debian-kernel@lists.debian.org
> 
> 
> Hi.
> 
> In a similar vein to what was reported by Roger Shimizu, it takes ages to
> compress with xz on an armel system with only 128MB of RAM. By default,
> (which is what is used) xz uses level 6 compression and that is what takes a
> lot of time to compress.
> 
> I switched to gzip and the initrd is quite larger. I just performed some
> tests with perf stat running 3 times a lot of commands to compress my
> current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than
> gzip -9 *and* generating a smaller file as a result.
[...]

Try zstd?

If you still feel you need this flexibility, I'm open to taking a patch
that allows specifying the compression level *only*.  I don't want to
allow specifying arbitrary options.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web