<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="https://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:openvz</id>
  <title>OpenVZ</title>
  <subtitle>OpenVZ</subtitle>
  <author>
    <name>OpenVZ</name>
  </author>
  <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/"/>
  <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom"/>
  <updated>2013-12-28T09:47:42Z</updated>
  <lj:journal userid="9392309" username="openvz" type="community"/>
  <link rel="service.feed" type="application/x.atom+xml" href="https://openvz.livejournal.com/data/atom" title="OpenVZ"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:46644</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/46644.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=46644"/>
    <title>Why we still use gzip for templates?</title>
    <published>2013-12-28T09:47:42Z</published>
    <updated>2013-12-28T09:47:42Z</updated>
    <content type="html">&lt;a href="http://openvz.org/Download/template/precreated" target="_blank" rel="nofollow"&gt;OpenVZ precreated OS templates&lt;/a&gt; are tarballs of a pre-installed Linux distributions. While there are other ways to create a container, the easiest one is to take such a tarball and extract its contents. This is what takes 99.9% of &lt;code&gt;vzctl create&lt;/code&gt; command execution.&lt;br /&gt;&lt;br /&gt;To save some space and improve download speeds, those tarballs are compacted with good ol' &lt;code&gt;gzip&lt;/code&gt; tool. For example, CentOS 6 template tar.gz is about 200 MB in size, while uncompacted tar would be about 550 MB. But why don't we use more efficient compacting tools, such as bzip2 or xz? Say, the same CentOS 6 tarball, compressed by xz, is as lightweight as 120 MB! Here are the numbers again:&lt;br /&gt;&lt;br /&gt;centos-6-x86.tar.gz: 203M&lt;br /&gt;centos-6-x86.tar.xz: 122M&lt;br /&gt;centos-6-x86.tar: 554M&lt;br /&gt;&lt;br /&gt;So, why don't we switch to xz which apparently looks way better? Well, there are other criteria to optimize for, except for file size and download speed. In fact, the main optimization target is container creation speed! I just ran a quick non-scientific test on my notebook in order to proof my words, measuring the time it takes to run &lt;code&gt;tar xf&lt;/code&gt; on a tarball:&lt;br /&gt;&lt;br /&gt;time tar xf tar.gz: ~7 seconds&lt;br /&gt;time tar xf tar.xz: ~13 seconds&lt;br /&gt;&lt;br /&gt;See, it takes twice the time if we switch to xz! Note that this ratio doesn't change much when I switched from fast SSD to (relatively slow) rotating hard disk drive:&lt;br /&gt;&lt;br /&gt;time tar xf tar.gz: ~8 seconds&lt;br /&gt;time tar xf tar.xz: ~16 seconds&lt;br /&gt;&lt;br /&gt;Note, while I call it non-scientific, I still ran each test at least three times, with proper syncs, rms and cache drops in between.&lt;br /&gt;&lt;br /&gt;Now, do we want to trade a double increase of container creation time for saving 80 MB of disk space. We sure don't!</content>
  </entry>
</feed>
