1 :
login:Penguin :
2008/06/28(土) 12:02:14 ID:yqbrlAKF さあ語れ!
lzmaは???
p7zip愛用してます。tarしてからだけどね。
最近は細かいこと考えずにlzmaばかりだな・・・ PCの性能は十分あるんだし
自分しか使わないファイルはlzma(.tar.lzmaとか)、 誰かに渡すファイルはgzとかbz2にしてる。
NTFSの圧縮ファイルシステムみたいなLZOlayer_fsってのを使ってる人がいるので、
DeveloperWorks Japan > Linux > FUSEによる独自ファイルシステムの開発
ttp://www.ibm.com/developerworks/jp/linux/library/l-fuse/index.html ここから辿ってファイルシステム一覧を見てたら、圧縮ファイルシステム一覧があった。
読み書きできて、安定してるやつは他にあるのかな。
ttp://fuse.sourceforge.net/wiki/index.php/FileSystems ・CompressedFileSystems - accessing files in a compressed image (gz, zlib, LiveCDs, etc.)
- compFUSEd
- FuseCompress
- LZOlayer_fs - Transparent compression filesystem
・ArchiveFileSystems - accessing files inside archives (tar, cpio, zip, etc.)
- unpackfs
- avfs - mount archive and compressed files, and access remote files
>>8 中身違うと思う。LGPLなLZOはffmpegのlibavutilにあった気ガス。あと7zにもあったような。
なぜgzipは解凍でもとのファイルが消える仕様?
lzmaよりbzip2のほうが早いしよく潰れるんだが・・・ ^−^;;;; (12:33:25)hoge~/$ time tar cf - emacs-21.4 | gzip -1 > emacs-21.4.tar.gz real 0m35.635s user 0m32.900s sys 0m4.500s (12:34:44)hoge~/$ time tar cf - emacs-21.4 | bzip2 -z -1 > emacs-21.4.tar.bz2 real 2m19.127s user 2m17.470s sys 0m3.970s (12:37:28)hoge~/$ time tar cf - emacs-21.4 | lzma -z -1 > emacs-21.4.tar.lzma real 2m22.816s user 2m20.920s sys 0m5.320s (12:40:18)hoge~/$ ls -l emacs-21.4.tar.* -rw-r--r-- 1 *** users 21538172 6月 30 12:37 emacs-21.4.tar.bz2 -rw-r--r-- 1 *** users 28265569 6月 30 12:34 emacs-21.4.tar.gz -rw-r--r-- 1 *** users 22247714 6月 30 12:40 emacs-21.4.tar.lzma
-9使うだろ常考 $ time gzip -9 emacs-21.4a.tar real 0m23.369s user 0m18.659s sys 0m2.363s $ time bzip2 -9 emacs-21.4a.tar real 1m9.675s user 1m3.954s sys 0m1.605s $ time lzma -9 emacs-21.4a.tar real 7m20.250s user 6m41.498s sys 0m3.793s $ ls -lSr emacs-21.4a.tar* -rw-rw-r-- 1 xxxx xxxx 12644142 Jun 30 15:00 emacs-21.4a.tar.lzma -rw-rw-r-- 1 xxxx xxxx 16031034 Jun 30 14:59 emacs-21.4a.tar.bz2 -rw-rw-r-- 1 xxxx xxxx 20403499 Jun 30 14:58 emacs-21.4a.tar.gz $ lzma -9の方が小さいよ。 死ぬほど遅いけど。
14 :
login:Penguin :2008/06/30(月) 15:51:13 ID:MmUObtGR
なぜgzip > bzip2?
15 :
12 :2008/06/30(月) 16:24:20 ID:t5z30P/R
>>13 -9 使いたいのはやまやまなんだが、手元のマシンがP2-400なんだw
lzmaの売りが圧縮率と思うが、時間がかかりすぎるぞ・・・・。
16 :
login:Penguin :2008/07/01(火) 14:49:11 ID:gSA6bD4u
どれだけ圧縮が遅くてもいい。 どれだけ圧縮にメモリを使ってもいい。 展開が激烈には遅くなく(たとえばgzipの数倍以内とか)で、 なおかつ、メモリ使用量がそれなり(たとえば、256MB以内とか)。 この条件でベストのものって何? 何がしたいかというと、 ディストリのインストールDVDを一枚のCDに圧縮したいわけです。 gzipなら4.7GBになるところを、無理やり700MB以内にできないか? 圧縮は、どんなに遅くてもいい。 たとえ、Quad Core で3ヶ月ぐらい掛かっても、 圧縮する価値はあると思う。 DVDなんてダウンロードできないよ!!!。
18 :
login:Penguin :2008/07/01(火) 16:02:48 ID:sogkEXkC
>>17 シャノンの定理は対象の情報源以外から情報を得られないから
成り立っているように見えるんだよ。
圧縮が遅いのは放っておけばいいので問題ないんだが、展開が遅い奴は嫌だな。
>>16 解凍は bzip2 より lzma のほうが速いよ。
圧縮時間も bzip2 並でよければ変わらんし。
・ Average compression ratio of LZMA is about 30% better than that of gzip, and 15% better than that of bzip2.
・ Decompression speed is only little slower than that of gzip, being two to five times faster than bzip2.
・ In fast mode, compresses faster than bzip2 with a comparable compression ratio.
>>16 釣りか?
それなら圧縮してる時間をダウンロードにあてれば解決するだろ。
>>9 の書庫ファイルシステムについてfuse-zipとの性能比較があった。
PerformancePage - VFS performance comparison
http://code.google.com/p/fuse-zip/wiki/PerformancePage 他の圧縮もlibzip使って比較してるのか分らないけど、 fuse-zipとavfs-fuseがunpackfsより軽いみたいだ。
それぞれ
CompressFileSystems(圧縮ファイルシステム)は、1ファイルごとにgzなど圧縮ファイルと対応させて管理されて、
ArchveFileSystems(書庫ファイルシステム)zip書庫などをマウントポイントからディレクトリとして使える物みたい
FuseCompress - compressed filesystem
http://www.miio.net/fusecompress 性能測定したらこんな感じになった
■ファイルサイズ(MyISAMのデータファイル)
file 1,127,594,052
(lzo) /tmp/lzo/file 294,154,987 (26.1%)
(gz) /tmp/gz/file 183,510,660 (16.3%)
(bz2) /tmp/bz2/file 未測定
■同一HDD: cp file file2
real 1m5.670s, user 0m0.187s, sys 0m6.112s
動作時のcpu利用率 10% (cp 10%)
■同一HDD(lzo): cp file /mnt/lzo/file
real 0m44.970s, user 0m0.310s, sys 0m4.768s
動作時のcpu利用率 50% (cp 10%, fusecompress 40%)
■同一HDD(gzip): cp file /mnt/gz/file
real 2m8.807s, user 0m0.331s, sys 0m4.469s
動作時のcpu利用率 100% (cp 4%, fusecompress 95%)
■同一HDD(bz2): cp file /mnt/bz2/file
動作時のcpu利用率 100% (cp 2%, fusecompress 98%)
■ヌル出力: cat file > /dev/null
real 0m21.486s, user 0m0.121s, sys 0m1.477s
cat 6%
■ヌル出力(lzo): cat /mnt/lzo/file > /dev/null
real 0m11.340s, user 0m0.211s, sys 0m1.406s
動作時のcpu利用率 60% (cat 10%, fusecompress 50%)
■ヌル出力(gzip): cat /mnt/gz/file > /dev/null
real 0m19.671s, user 0m0.152s, sys 0m1.153s
動作時のcpu利用率 100% (cat 6%, fusecompress 94%)
■ヌル出力(bz2): cat /mnt/bz2/file > /dev/null
動作時のcpu利用率 100% (cat 1%, fusecompress 99%)
■lzop -o file.lzo file real 0m43.200s, user 0m8.009s, sys 0m2.727s lzop 24%
$ time rzip -9 emacs-21.4a.tar
real 0m31.523s
user 0m28.823s
sys 0m1.306s
$ ls -l emacs-21.4a.tar*
-rw-rw-r-- 1 xxxx xxxx 14472688 Jul 7 13:49 emacs-21.4a.tar.rz
$
>>13 と同じ環境。
合わせて評価すると速さと圧縮率のバランスがいいかもしれない。
lzmaはシングルスレッドだし、p7zipはパイプで使えないしで、 lzmaの4.999α版コンパイルしてみたけど、マルチスレッドにならないし。 7zファイル形式がパイプで使えない原因らしいから、 p7zipがlzmaファイル形式をサポートして、パイプで使えるようになったら良いな〜
>>26 これいいな〜と思ったら標準入出力に未対応か・・・
lbzipもpbzip2とか・・・
31 :
login:Penguin :2009/06/12(金) 18:42:18 ID:WAZGDfix
ソースコードの配布じゃ、今のところ、tar.gz か tar.bz2 がほとんど
>>31 pbzip2はよさげだね
>>32 tar.gzは互換性のために生き続ける。
lzmaも場合によってはメリットも大きいはずなのに普及してはきてるけど
あまり表に出てこないのはなんでだろう。
ユーザが入れてなさそうな圧縮形式なら、誰だって配布に使わない。 配布に使われないんだから、ユーザもインストールする動機がない。 ...の環から、なかなか抜け出せないことが多いだろうな。 ディスクもメモリもネットワークも豪奢な当世、圧縮率に拘るのも少数派だろうし。 あ、lzmaも、ぽちぽち使われているよ。 Linuxカーネル2.6.30とか。
>>34 それは書こうかと思ったけどまだ新しすぎるよな・・って思って普及してきてるに止めた。
7zipとしてWindowsでかなり有名なんじゃないかと。
elinksか何かがgzip,deflate以外にbzip2,lzmaが使えたと思うが
ネットでは対応サーバーが皆無だわな
いつの間にかgnu tarがlzmaに対応してるな。 dpkgの依存にlzmaが入っていたりもするし、そろそろlzmaが入ってない環境っていうのは珍しいくらいなのかも。
dpkgでほほぅ、と思ったがtarもか。 〜1GhzのCPUでは結構しんどい仕事だから標準をどうするかは難しそう
>>33 lzmaは解凍にメモリを多く使うんじゃなかたっけか
それで使いにくいんじゃないかなぁ
ファイルサイズとMD5メモしておけば、 そのうち元のファイルが復元できると言い張る奴がいたな
ファイルで思い出したが、 file(1)では、まだlzma形式を認識できないようだ 少なくとも file-5.00 は。
42 :
login:Penguin :2009/06/22(月) 15:09:23 ID:nPX8bYX0
xz
>>41 へぇー。
でも.exeってウィルス疑惑で忌避される傾向にある気がする。
自己解凍exeは不安なのに 解凍したzip中のexeは普通に開く不思議
lzfかなりいいね。圧縮率に目をつぶれば。 lzoイラネ。 ホントはbzip2系が画像圧縮で有利な技術だから使いたいんだけど、 展開が遅いのがねー。
46 :
login:Penguin :2010/05/23(日) 10:18:27 ID:JQh/i7Pu
gnuのソースやlinuxの起動イメージも lzmaになってきたな 復元は圧縮より速いんだっけ
bzip2 は展開が遅いから、さっさと lzma 系のどれかに置き換わって欲しいな。
>>48 gzipと違って展開プログラムがアセンブラ化されてないからねぇ。
実装としては枯れてるんだからあとは移植するだけなんだが。
追記。bzip2のデコード分のソースコードを追っかけてみたら、 巨大なswitch文がある関数の中と外を膨大な回数行き来するような構造になってた。 VS2010で最大限の最適化をかけてasmを吐き出してみたけどほとんど最適化されてない。 これを逐語的にハンドアセンブルするのはかなり骨だろうなー。
51 :
login:Penguin :2010/07/23(金) 08:23:17 ID:+OeBNNzx
はやくなあれ〜
xz 試してみたけどいいね 古いマシンだとcpu もメモリも辛いけど
53 :
login:Penguin :2012/08/05(日) 14:48:46.70 ID:wvwj6mGz
あげ
>>52 圧縮率最高だよ
圧縮はかなり遅いが展開は速い
$ lzma -h lzma 9.22 Copyright (C) 2006 Ville Koskinen Based on LZMA SDK 9.22 Copyright (C) 1999-2011 Igor Pavlov Usage: lzma [flags and input files in any order] -c --stdout output to standard output -d --decompress force decompression -z --compress force compression -k --keep keep (don't delete) input files -f --force force overwrite of output file and compress links -t --test test compressed file integrity -S .suf --suffix .suf use suffix .suf on compressed files -q --quiet suppress error messages -v --verbose be verbose -h --help print this message -L --license display the license information -V --version display version numbers of LZMA SDK and lzma -1 .. -2 fast compression -3 .. -9 good to excellent compression. -7 is the default. --fast alias for -1 --best alias for -9 (usually *not* what you want) Memory usage depends a lot on the chosen compression mode -1 .. -9. See the man page lzma(1) for details.
圧縮・伸張のマルチコア対応ってどうなっているんでしょうね
>>56 xzなら-Tでスレッド数を指定できるな。
>>57 マジで? version教えてくださいな。
こちらは、
xz --version
xz (XZ Utils) 5.1.0alpha
liblzma 5.1.0alpha
誰か教えてちょうだい。 年も明けたことだし去年のログファイルでも圧縮するかと思って、 tar.xz に圧縮してみたんだけど、tar に引数を渡すのに ディレクトリ名を渡すのと、ファイル名を渡すので 圧縮後のファイルサイズが 3倍くらい違うんだけどなんで? $ apt-show-versions tar bzip2 gzip xz-utils bzip2/squeeze uptodate 1.0.5-6+squeeze1 gzip/squeeze uptodate 1.3.12-9 tar/squeeze uptodate 1.23-3 xz-utils/squeeze uptodate 5.0.0-2 # ログファイル数 212、logディレクトリ容量 703MB $ find log |wc -l 212 $ du -m log 703 log みたいな環境で、 tar cJf logs_with_dir.tar.xz log tar cJf logs_without_dir.tar.xz log/*.log ってそれぞれ実行。
60 :
59 :2013/01/01(火) 21:32:41.16 ID:pDNF1piR
すると、これ↓くらい違っちゃうんだよね。 ls -sh1 *.tar.xz 416K logs_without_dir.tar.xz 1.3M logs_with_dir.tar.xz $ xz -l logs_*_dir.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir.tar.xz 1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir.tar.xz ------------------------------------------------------------------------------- 2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files んで、試しに 7z で圧縮するとこれくらい。 $ 7z a logs.7z log $ ls -sh1 *.7z 428K logs.7z なんで? ちなみに tar.gz や tar.bz2 で試すとほとんど差は出なかった。 何も困ってはいないんだけど不思議なので聞いてみた。
>>59 > tar cJf logs_with_dir.tar.xz log
> tar cJf logs_without_dir.tar.xz log/*.log
"*.log"以外のファイルやディレクトリがあるんじゃないのか。
前者はlogディレクトリ以下の全てのファイルとディレクトリを対象とするが、
後者はlogディレクトリ以下の"*.log"のみを対象としている。
62 :
59 :2013/01/06(日) 18:01:23.59 ID:zqjwY8tC
>>61 おー、やっと反応があった。
> "*.log"以外のファイルやディレクトリがあるんじゃないのか。
それが logディレクトリ配下には "*.log"しか置いてないのよ。
$ tar tvJf logs_without_dir.tar.xz | wc -l
210
$ tar tvJf logs_with_dir.tar.xz | wc -l
211
1行違うのはディレクトリ自身の分ね。
それに
>>60 の "xz -l" の結果を見ても、
Uncompressed のサイズはどっちも 702.6 MiB だし。
ためしに tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz してみるとどう?
64 :
59 :2013/01/07(月) 18:50:41.98 ID:dCQMeIg4
>>63 両方↓やってみた。
$ tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz
$ tar cf - log|xz > logs_with_dir_pipe.tar.xz
$ ls -sh1 logs_with*_dir_pipe.tar.xz
1.3M logs_with_dir_pipe.tar.xz
416K logs_without_dir_pipe.tar.xz
$ xz -l logs_with*_dir_pipe.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir_pipe.tar.xz
1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir_pipe.tar.xz
-------------------------------------------------------------------------------
2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files
やっぱり、当たり前と言えば当たり前だけど、結果は同じ。
あんまり関係ないと思うけど、念の為ログの説明しとくと、
hyperestraierインデックス作成時(maildir対象)のログね。
cronで回した際のログなので使用文字列の重複率非常に高し。
65 :
59 :2013/01/07(月) 19:57:39.25 ID:dCQMeIg4
んで、ちょっとテストケースを作ってみた。 mkdir -p /somewhere/test/dir/log cd /somewhere/test/dir time for i in $(seq -w 1 1000) do for j in $(seq -w 1 2000) do echo "test log text line ${j}" done > log/${i}.log done $ du -m log 47 log $ ls log|wc -l 1000 $ tar cf logs_with_dir.tar log $ tar cf logs_without_dir.tar log/*.log $ tar czf logs_with_dir.tar.gz log $ tar czf logs_without_dir.tar.gz log/*.log $ tar cjf logs_with_dir.tar.bz2 log $ tar cjf logs_without_dir.tar.bz2 log/*.log $ tar cJf logs_with_dir.tar.xz log $ tar cJf logs_without_dir.tar.xz log/*.log
66 :
59 :2013/01/07(月) 19:58:52.41 ID:dCQMeIg4
結果: $ xz -l logs_with*dir.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 16.9 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz 1 1 13.8 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz ------------------------------------------------------------------------------- 2 2 30.7 KiB 92.8 MiB 0.000 CRC64 2 files $ gzip -l logs_with*dir.tar.gz compressed uncompressed ratio uncompressed_name 5114261 48650240 89.5% logs_with_dir.tar 5114237 48650240 89.5% logs_without_dir.tar 10228498 97300480 89.5% (totals) ※ bzip2 は "-l" オプションなし $ ls -al logs_with*tar* -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_with_dir.tar -rw-r--r-- 1 hiro hiro 549025 2013-01-07 10:28 logs_with_dir.tar.bz2 -rw-r--r-- 1 hiro hiro 5114261 2013-01-07 10:27 logs_with_dir.tar.gz -rw-r--r-- 1 hiro hiro 17336 2013-01-07 10:30 logs_with_dir.tar.xz -rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_without_dir.tar -rw-r--r-- 1 hiro hiro 543453 2013-01-07 10:30 logs_without_dir.tar.bz2 -rw-r--r-- 1 hiro hiro 5114237 2013-01-07 10:27 logs_without_dir.tar.gz -rw-r--r-- 1 hiro hiro 14120 2013-01-07 10:31 logs_without_dir.tar.xz logs_with_dir.tar.xz の方が 1.2倍くらい大きくなる。 三倍も差があるわけじゃないけど、圧縮率の差が大きいのは やっぱり tar.xzなんだよなぁ。 *.tar 大きさ同じなのになー、やっぱ不思議。
そんなに差出なかった -rw-r--r-- 1 aaa users 5118621 1月 7 22:29 logs_with_dir.tar.gz -rw-r--r-- 1 aaa users 13828 1月 7 22:24 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13796 1月 7 22:26 logs_without_dir.tar.xz xzのやつをxz -dで解いた後xz -9で固めたらこうなった -rw-r--r-- 1 aaa users 48650240 1月 7 22:24 logs_with_dir.tar -rw-r--r-- 1 aaa users 48650240 1月 7 22:26 logs_without_dir.tar -rw-r--r-- 1 aaa users 13692 1月 7 22:24 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13584 1月 7 22:26 logs_without_dir.tar.xz
68 :
59 :2013/01/07(月) 23:56:16.32 ID:dCQMeIg4
>>67 むむ、ぬぁにぃぃぃ、こっちの環境のせいなのかぁ?
こっちでも、 xz -d して xz -9 してみた。
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:37 logs_with_dir.tar
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:40 logs_without_dir.tar
-rw-r--r-- 1 hiro hiro 16972 2013-01-07 23:37 logs_with_dir.tar.xz
-rw-r--r-- 1 hiro hiro 13668 2013-01-07 23:40 logs_without_dir.tar.xz
やっぱり 1.2倍くらい違う。
えーと、こっちの環境は debian 6.0.6/squeeze で
$ tar --version
tar (GNU tar) 1.23
$ xz --version
xz (XZ Utils) 5.0.0
liblzma 5.0.0
debian パッケージ的には、
$ apt-show-versions tar xz-utils
tar/squeeze uptodate 1.23-3
xz-utils/squeeze uptodate 5.0.0-2
なんだけど、そっちの環境を教えてもらえますか?
69 :
67 :2013/01/08(火) 00:05:54.47 ID:TM+tkKtJ
Slackware 14.0 tar (GNU tar) 1.26 xz (XZ Utils) 5.0.4 liblzma 5.0.4 だった
70 :
67 :2013/01/08(火) 00:24:54.72 ID:Yi/2g8hy
ひょっとしてと思ってたけど、これ多分メモリの搭載量によって結果変るんだと思う さっきやったPCでまた新しくデータを作ってからlogs_with_dir.tar.xzを作って それを別の二台に送って解凍してからまた固めたらこうなった 一番上が最初のPC Mem: 1165120 696316 468804 0 10940 328680 Mem: 3915520 129536 3785984 0 9660 85404 Mem: 767544 97744 669800 0 15752 67784 -rw-r--r-- 1 aaa users 13908 1月 8 00:09 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 13828 1月 8 00:12 logs_with_dir.tar.xz -rw-r--r-- 1 aaa users 16948 1月 8 00:16 logs_with_dir.tar.xz xzとtarは全部同じバージョン
最後のPCでwithoutのほう試すの忘れて電源切っちゃったけど 多分13800前後になるんだと思う なんでか分からないけどディレクトリ付きのほうが 圧縮するときメモリ使うってことじゃないかな
と適当なこと書いたけどxzやってる間そんなメモリ使ってないな
73 :
59 :2013/01/08(火) 00:56:31.29 ID:5U01eE+J
>>70 おー、そういう検証はとてもありがたい。
しかし Slackwareが出てくるとは…、年季入ってそうっすね。
こっちのメモリは、↓な感じ。
Mem: 3371996 2639292 732704 0 264628 1622812
まさにwithoutの方頼もうと思ってたら、電源切っちゃいましたか…
メモリの使い方については、xz の man pageの "Memory usage"に
いろいろ書いてありますね。
でも、メモリ搭載量で圧縮率に変動があるとしても、元々のお題の
ディレクトリを含む/含まないによって圧縮率が変わることへの
直接の回答にはなっていないような感じ…
んで、今さらながら より新しいバージョンの xz-utilsの
NEWSを見てみたんだけど、
http://git.tukaani.org/?p=xz.git;a=blob;f=NEWS;hb=HEAD 5.0.3 (2011-05-21)
* liblzma fixes:
- lzma_stream_buffer_encode() no longer creates an empty .xz
Block if encoding an empty buffer. Such an empty Block with
LZMA2 data would trigger a bug in 5.0.1 and older (see the
first bullet point in 5.0.2 notes). When releasing 5.0.2,
I thought that no encoder creates this kind of files but
I was wrong.
なんかこれっぽい感じ。
今日はもう寝るけど、明日にでも sid の
新しいバージョンビルドして確認してみよう。
74 :
67 :2013/01/09(水) 22:44:39.42 ID:Q9Cbtgql
>>67 のときと同じのを展開した後はこれで
tar cJf logs_with_dir2.tar.xz log
tar cJf logs_without_dir.tar.xz log/*.log
Mem: 767544 97056 670488 0 15600 67276
-rw-r--r-- 1 aaa users 13908 1月 9 22:33 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 16948 1月 9 22:36 logs_with_dir2.tar.xz
-rw-r--r-- 1 aaa users 13812 1月 9 22:34 logs_without_dir.tar.xz
Mem: 1165120 359552 805568 0 7776 196436
-rw-r--r-- 1 aaa users 13908 1月 8 00:47 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 13828 1月 9 22:35 logs_with_dir2.tar.xz
-rw-r--r-- 1 aaa users 13812 1月 9 22:36 logs_without_dir.tar.xz
同じPCでも今回はサイズが微妙に違った
75 :
59 :2013/01/14(月) 04:16:03.55 ID:ccIYmHSp
明日とか言いつつ、時間たっちゃったな。
てことで xz-utils 5.1.1alpha+20120614 で確認してみた。
なんで 5.0.4じゃないかというと、debian sid に 5.0.4 がなかったから。
試した結果だけど、若干前よりどちらも圧縮率は上がったけど、
圧縮率の差はそのまま。
>>73 の 5.0.3のliblzma fixesは関係なかったみたい。
$ ls -al logs_with*tar*
-rw-r--r-- 1 hiro hiro 16920 2013-01-14 03:54 logs_with_dir.tar.xz
-rw-r--r-- 1 hiro hiro 13836 2013-01-14 03:55 logs_without_dir.tar.xz
$ xz -l logs_with*dir.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 16.5 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz
1 1 13.5 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz
-------------------------------------------------------------------------------
2 2 30.0 KiB 92.8 MiB 0.000 CRC64 2 files
>>67 の人が検証してくれたおかげでとりあえず確認できたのは、
どうやらメモリ環境によって圧縮率は変動するらしいってことくらいか。
確かにそれらしいことが xz の man pageの "Memory usage"に
書かれてるけど、ディレクトリありなしによって圧縮率が変動する
ことの理由にはなってないよなぁ。
てことで、なんかすっきりしないけど、解明はあきらめました。
>>67 の人は協力してくれてありがとう。
誰かが xz-utilsのソース読み込んで、
この現象をすっきり説明してくれることを願う。
pxz
>>67 >>75 今更だが気になったので実験。
ファイルはGNUのtar-1.26.tar.xzを使用した。
Debian wheezy 7.0
tar 1.26
xz (XZ Utils) 5.1.0alpha
liblzma 5.1.0alpha
Mem: 8104148 2631116 5473032 0 21232 1628468
これをgz,bzip2,xzでそれぞれ -c をつけてリダイレクトして圧縮する。
$ tar -cf tar_with.tar tar-1.26
$ tar -cf tar_without.tar tar-1.26/*
$ du -b * | sort
14899200 tar_with.tar
14899200 tar_without.tar
1763224 tar_without.tar.xz
1788988 tar_with.tar.xz
2348783 tar_without.tar.bz2
2360563 tar_with.tar.bz2
3455923 tar_without.tar.gz
3456187 tar_with.tar.gz
となった。.tarを比較してみる。
$ diff tar_with*.tar
バイナリファイル tar_with.tar とtar_without.tar は異なります
と出力されたのでtarの方に原因があると思われ。
ディレクトリの有無によるファイルサイズの違いについては
xz-utilsよりtarのソースを読んだ方がいいかもしれない。