FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-14-2011, 05:54 PM
Chris Lumens
 
Default Split compression into separate methods; use xz to compress initrd

> xz compression makes the initrd 33% smaller (136M -> 90M). The extra
> memory overhead at decompression time is negligible: testing showed
> that any system with enough RAM to use the gzip-compressed initrd was
> also able to load the xz-compressed initrd with no trouble.
>
> Note that '--check=crc32' is needed because the kernel doesn't know
> how to perform the default xz integrity check (crc64).

If it's okay with mgracik, it's okay with me. I'm happy to see the
initrd get below 100 MB, which was my original goal.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-17-2011, 06:30 PM
Will Woods
 
Default Split compression into separate methods; use xz to compress initrd

On Thu, 2011-02-17 at 07:54 -0800, John Reiser wrote:
> On 02/17/2011 06:40 AM, Will Woods wrote:
> > The most significant reason we might want to use xz instead of lzma is
> > integrity checking - gzip and xz use crc32, lzma has none.
>
> That's not really true. If the header is OK and if lzma decompression
> reaches EOF on input with the expected state (0==accumulator &&
> bytes_written==original_length), then that is an integrity check
> that is broadly equivalent to crc32. lzma decompression is
> equivalent to a "arithmetic long division" of the input encoded
> representation; crc32 is a "polynomial long division" of the
> bitstring.

Okay then - no real useful difference between xz and lzma, at least for
our purposes here.

> The value added by crc32 is low. Because crc32 is orthogonal to
> the algorithmic check, then the probability that crc32 catches
> an otherwise-undetected error is 2**-32.
>
> The cost of crc32 is high. crc32 pollutes the data cache, often
> equivalent to flushing a major portion of L1. In the name of speed,
> common implementations use many kilobytes of tables. The adler32
> checksum is *MUCH* better: no tables, less code, faster, no cache
> pollution. adler32 is about 1/4096 less powerful (65521/65536)
> in detecting impostors. crc32 is trivial in hardware and has
> mindshare. But in software, crc32 should be replaced by adler32.

Okay, sure. As soon as there's a --check=adler32 switch for xz, and the
kernel will handle the resulting image, we'll switch.

-w

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 02:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org