mkuzip: -S 1TB ― 2006年05月13日 12時20分08秒

さて、同じブロックを指す効果がどれくらいのものだか実験である。1 TB 分のメモリを割り当て、/dev/null と /dev/zero を mkuzip してみる。

まずは /dev/null がどの位の大きさになるか計算する。以下の計算は 1TB の大きさを求め、ブロックサイズで割る。ブロックサイズは 130048 を使う。一つのポインタが、64 bit なので 8 byte である。それを 1k の 1024 で割ると、約 66 MB になる。これは、ヘッダのほとんどとゼロブロックが含まれていないで、実際はこれよりも大きくなる。 


%dc
1024 1024 1024 1024 * * *  p
1099511627776
130048 / p
8454660
64 8 / p
8
 * p
67637280
 1024 / p
66052
-s のクラスタサイズの初期値は 16384 byte になっている。なぜ、130048 を使うかというと、 

%dc
3 k
130048 16384 / p
7.937
66 * p
523.842
というわけだ。クラスタが約八倍の大きさになっている。それを 66MB で掛けると、約 0.5GB。実メモリより大きくなってしまうので、回避。slashing の嵐となり、身動きが取れない程の風が吹きまくる事になる。

さて、実験開始。 


%time mkuzip -S 1t -s 130048 -o null.uzip /dev/null
0.130u 0.449s 0:03.97 14.3%     10+89853k 6+486io 4pf+0w
%time mkuzip -S 1t -s 130048 -o zero.uzip /dev/zero
^C493.464u 54.457s 9:18.51 98.1%        10+6840k 0+84io 0pf+0w
%du -s *uzip
66128   null.uzip
/dev/zero は十分近く経っても、2% ぐらいしか終っていなかったみたいなので、諦めた。恐らく二時間ぐらいかかると思う。なお、2% は top の SIZE と RES から求めた進行状況。/dev/null は四秒にも満たないうちに終った。ゼロ埋め立てはほぼ瞬時に終るみたいだ。

でも、1TB が 66MB になった。実は、最初は mkuzip でデフォルトのブロックサイズを使ったら、512 MB ぐらいのヘッダが必要だったらしく、大量のメモリを確保され、身動きが取れなくなったので強制終了。先に計算しておくべきだったが、怠慢だったのでなどと口が裂けても言えない。

話は元に戻って、1TB の /dev/zero の結果を計算する。 


%mkuzip -v -s 130048 -S 10M -o /tmp/x /dev/zero
cluster #1, in 130048 bytes, out 149 bytes
cluster #2, in 130048 bytes, out 149 bytes
cluster #3, in 130048 bytes, out 149 bytes
cluster #4, in 130048 bytes, out 149 bytes
^C
%dc
1024 1024 1024 1024 * * * p
1099511627776
130048 / p
8454660
149 * p
1259744340 1024 / 1024 / p
1201
mkuzip は -v を付けると、ブロックの圧縮後の大きさを教えてくれる。149 byte らしい。1TB は 1099511627776 byte。それを一ブロック分の 130048 で割る。全てで 8454660 ブロック。149 を掛けた後、MB の単位に落とす。ほぼ 1GB らしい。塵も積もれば山となる。そのまま。でも、今回の実験は全然実用的ではなかったとは思う。

余談だが、bzip2 だったら、1TB ぐらいの連続したゼロだったら、3KB ぐらいに収まるような気がする。後で、実験するとしよう。

前回。

by uyota [fs] [Programming] [コメント(0)｜トラックバック(0)]