tar.xz とそれに関わるアーカイブ、圧縮に関わる復習など

○ Google GlassのKernel Sourceはxz形式で圧縮されている

https://code.google.com/p/google-glass-kernel-source/

2013-05-01 現在、 kernel-glass-XE04.0-RC06 が公開されている。このソースの配布には、tar.xz という拡張子が使われている。tar.gzではない。

gz形式については個人的には馴染みがあるが、念の為Wikipediaのgzipの解説のリンクも貼っておく。

一方、今回のxz形式は毎度見るようなものではない気がしたのでひと通りまとめた。

○ xz形式とは

つまり、より圧縮効率が高いのがxzなのでGoogleは今回それをつかいました、まる。

手元の環境での(GNU) tarの対応状況を見てみる。Ubuntu 12.04 LTS, Debian Wheezy (testing) が tar 1.26, Debian Squeeze (stable) が 1.23。 xz形式をパッケージでインストールできるtarで利用できない環境は見当たらない。

○ どれだけ圧縮効率が良いのか。そしてどれだけ余分に遅いのか

オプション等による違いをとりあえず考えなくて済むよう、tar xJvf で解凍したディレクトリを再びtar cvf, tar czvf, tar cJvf で圧縮した際のサイズを比較してみよう。余談だが J大文字だ、じぇええええええい! (j は bzip2、つまり tar.bz などで使う)

  • tar : 465,530,880 bytes (0.548 (秒))
  • tar.gz : 102,636,192 bytes (12.545 (秒))
  • tar.xz : 68,923,324 bytes (3:13.19 -> 3分以上)
非常にラフに言えば、今回のケースではxz形式はgz形式の67%くらいまで圧縮できている。

こういう場合、圧縮・解凍にかかる時間が割を食うのが一般的と思う。(zshの) time で計測 (stdoutを/dev/null) した際のtotalの値を括弧内に書いた。なお、書き込み先はSSDでext4 (Debian Wheezy の多分デフォルト)。

解凍時の速度差は読者の興味に応じて試すと良い。私の手元で試したケースでは、圧縮時ほどの速度差はない。tar.gzに対してtar.xzは2倍程度遅いが、どちらも数秒という単位で日常の作業に使うのならまず無視できる。

今回のケースだけで言えば配布にxz形式を用いるのは妥当、と言える気がする。つまり、圧縮効率は高いが圧縮自体は非常に遅く、しかし解凍はそこまで遅くない。配布向けだ。

なお、私が手元で試した環境はそこそこ(現時点で)速いマシンで試している (詳細な環境はめんどうなので省略する)。ストレージがHDDかつCPU・メモリの弱い環境では、xz形式の大規模ファイル群の圧縮はそれなりに苦痛だろう。解凍も目に見える程度には遅いかもしれない。とはいえ、今回のソースのサイズであれば我慢できる範囲とも言える。

HDDではないが、Sandisk のClass 10 (16GB) で武装したRaspberry Piで、上記と同様のファイルを圧縮・解凍してみた。
  • 解凍が約2分15秒。
  • 圧縮が (日記はここで途切れている)
失礼しました。
  • 圧縮が 約59分46秒
圧縮もさることながら、解凍に2分かかるのか……

参考まで、tar czvfでは約7分42秒だった。

# 以前の記事中にSDカードのパフォーマンスがRaspberry Piの律速になりかねないという懸念を抱いたのでカードを変えた。ただ、Raspberry PiがそもそもSDHCを満足にハンドルできるのかはよくわからない。http://elinux.org/RPi_SD_cards によると、まぁ出てる気がするんだけど。このあたり、自分でパフォーマンス計測をしたくなるほどにはRaspberry Piにまだ入れ込んでない。

○ tar ってそういえばなんだ

複数のファイルを連結して1つのファイルにするプログラムで、tar自体は圧縮をしない。プログラマならば、http://www.redout.net/data/tar.html とかを見ればイメージをつかみやすいかもしれない。

xz形式のWikipedia記事を再度見てみるともう少し全体像がつかめる可能性がある。
xzは、gzipやbzip2のように、複数の圧縮ファイル結合をサポートしているが、二つ以上のターゲットファイルを一つのアーカイブにまとめることはできない。その代わり、xzはtarやcpioなどUNIXによって作られたプログラムのように、アーカイブされたファイル自身の圧縮に使用されることが多い。 (強調 引用者) 
tar自体は圧縮しない。最初の3つのサイズ比較をもう一度見よう。tarの結果はとっても大きい。全ファイルを結合したようなものだからだ。

○ man tar
このマニュアル・ページではGNU版 tar , 即ち tarfile として知られているアーカイブ・ファイルにファイルを格納したり抽出する  為のアーカイブ・プログラムについて説明する。  tarfile はテープドライブ上に作成することも出来る。 しかし、 tarfileを通常のファイルに書き込む事もよく行なわれている。 tar への最初の引数は、オプション Acdrtux  のいずれかでなくてはならない。  この後にはどのオプション機能を指定する事も出来る。 tar への最後の引数はアーカイブすべきファイル又はディレクトリ名である。 ディレクトリ名を指定した場合は常に、そのサブディレクトリもアーカイブに 含められる。
特に初めてtarコマンドに触れるというケースでは比較的役に立たない解説のような気がするのだが、気のせいだろうか。

Tar stores and extracts files from a tape or disk archive.
     The first argument to tar should be a function; either one of the letters Acdrtux, or one of the long function names. A function letter need not be prefixed with ``-'', and may be combined with other single-letter options.  A long function name must be prefixed with --.  Some options take a parameter; with the single-letter form these must be given as separate arguments.  With the long form, they may be given by appending =value to the option.
英語はましだった。一応EXAMPLEセクションもあるし。

tarは古き良きテープバックアップでも使われたという。そもそもTape ARchive の略である。バックアップに興味があれば以下も



○ 注意

特にパフォーマンス計測については適当という点には留意していただきたい。ただ、xzが特にRaspberry Pi上で死ぬほど遅いといった部分は多分他の環境でも概ね変わらないだろう。特に圧縮が遅い点については、ストレージというよりはメモリサイズじゃないかと思うが、詳細は興味を持ちそうな他の人に譲る。

○ 追記

Facebook経由で以下のリンクを頂いた。
読んでいて気づいたが上記全体で"v"オプションは要らない (verbose) し、それぞれの圧縮オプション指定ではなくaを使えば良いようだ。なるほどなるほど。

○ まとめ

仕事にもどれよぅ

このブログの人気の投稿

LibreOfficeで表紙、目次、本体でフッターのページ番号のスタイルを変える

WiiUのコントローラが通信不良に陥った話

技術書典2 あ-03 『もわねっとのPythonの本』