<div dir="ltr"><div><div>FYI, xz with multithreading support (5.2 release) has been marked as stable yesterday.<br><br></div>Regards,<br></div>Bartłomiej Piotrowski<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 24, 2014 at 12:32 PM, Bartłomiej Piotrowski <span dir="ltr"><<a href="mailto:bpiotrowski@mirantis.com" target="_blank">bpiotrowski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 Nov 2014, at 12:25, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>> wrote:<br>
> I did this exercise over many iterations during Docker container<br>
> packing and found that as long as the data is under 1gb, it's going to<br>
> compress really well with xz. Over 1gb and lrzip looks more attractive<br>
> (but only on high memory systems). In reality, we're looking at log<br>
> footprints from OpenStack environments on the order of 500mb to 2gb.<br>
><br>
> xz is very slow on single-core systems with 1.5gb of memory, but it's<br>
> quite a bit faster if you run it on a more powerful system. I've found<br>
> level 4 compression to be the best compromise that works well enough<br>
> that it's still far better than gzip. If increasing compression time<br>
> by 3-5x is too much for you guys, why not just go to bzip? You'll<br>
> still improve compression but be able to cut back on time.<br>
><br>
> Best Regards,<br>
> Matthew Mosesohn<br>
<br>
</span>Alpha release of xz supports multithreading via -T (or —threads) parameter.<br>
We could also use pbzip2 instead of regular bzip to cut some time on multi-core<br>
systems.<br>
<br>
Regards,<br>
Bartłomiej Piotrowski</blockquote></div><br></div>