<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 27, 2020 at 7:46 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2020-11-27 at 18:35 +0100, Arne Wiebalck wrote:<br>
> Hi,<br>
> <br>
> I did a quick test (one data point):<br>
> <br>
> - the image build time increased by 10 mins<br>
>    (on a VM, this is more than double compared to gzip)<br>
> - but: the resulting image size is ~30% smaller (421 vs 297 MB)<br>
> - the cleaning time (unpacking on bare metal!) increased by ~30 seconds<br>
> <br>
that is one of the main trade offs the lzma compression makes<br>
it front loads the computeational load to the comppression step<br>
requireing both more ram and time to do the initall compression while<br>
also achiviving a better compresison ratio while allowing light weight<br>
clients to decompress it without similar increase the time/ram requirement for the client.<br>
you may also want to consider the .xz format<br></blockquote><div><br></div><div>Is it wildly supported for initramfs compression? I can, of course, try, but maybe you know.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
lzma and lzma2 have now been supperceed by .xz <br>
<a href="https://en.wikipedia.org/wiki/XZ_Utils" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/XZ_Utils</a><br>
<br>
.xz format is becomming more an d more commen fro things liek compress kernel modules and packages.<br>
<br>
> So, lzma looks like a good option to reduce the image size which<br>
> we had to do in our deployment already to address boot issues<br>
> (we removed some packages).<br>
> <br>
> Keeping gzip as the default and offering lzma as an option to<br>
> start with as suggested by Sergii seems like a good way forward.<br>
> <br>
> I also think it would be good to have someone else test as well<br>
> to have another data point :-)<br>
> <br>
> Cheers,<br>
>   Arne<br>
> <br>
> <br>
> On 27.11.20 14:00, Sergii Golovatiuk wrote:<br>
> > Hi,<br>
> > <br>
> > LZMA causes very high CPU and memory usage for creating images, leaving <br>
> > less resources for other processes. If Ironic is running alongside with <br>
> > other services that may cause significant impact for them. I would leave <br>
> > gzip option as default, would introduce --lzma as well as --gzip and use <br>
> > lzma on 5-10% of our CI resources to test how it goes. Then after a <br>
> > significant amount of testing we could turn it on as default. Proper <br>
> > deprecation should be applied here as well IMHO.<br>
> > <br>
> > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a> <br>
> > <mailto:<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>>>:<br>
> > <br>
> >     Hi folks,<br>
> > <br>
> >     I've been playing with ways to reduce the size of our IPA images.<br>
> >     While package removals can only save us tens of megabytes, switching<br>
> >     from gzip to lzma reduces the size by around a third (from 373M to<br>
> >     217M in my testing).<br>
> > <br>
> >     What's the caveat? The unpacking time increases VERY substantially.<br>
> >     On my nested virt lab the 217M image took around 5 minutes to<br>
> >     unpack. I'm not sure how much it will impact real bare metal, please<br>
> >     feel free to test<br>
> >     <a href="https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371</a><br>
> >     and tell me.<br>
> > <br>
> >     So, what do you think? Switching to lzma by default will likely<br>
> >     affect CI run time (assuming we still have DIB jobs somewhere...)<br>
> >     and development environments, but it will also provide a visible<br>
> >     reduction in the image size (which benefit all environments). Large<br>
> >     TripleO images may particularly benefit from this (but also<br>
> >     particularly affected by the unpacking time).<br>
> > <br>
> >     Feedback is very welcome.<br>
> > <br>
> >     Dmitry<br>
> > <br>
> >     -- <br>
> >     Red Hat GmbH, <a href="https://de.redhat.com/" rel="noreferrer" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn,<br>
> >     Commercial register: Amtsgericht Muenchen, HRB 153243,<br>
> >     Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs,<br>
> >     Michael O'Neill<br>
> > <br>
> > <br>
> > <br>
> > -- <br>
> > SergiiGolovatiuk<br>
> > <br>
> > Senior Software Developer<br>
> > <br>
> > Red Hat <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a>><br>
> > <br>
> > <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a>><br>
> > <br>
> <br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>