柘植です。こんにちは。
On Sat, 14 Feb 2004 23:45:34 +0700
[knoppix:2958] Re: リマスタ時の奇怪現象
Shiori Tamura <shiori_tamura@xxxxxxxxxxx> wrote:
> 「リマスタ時の奇怪現象」に関してですが，何せ実験にたいへん時間がかかる
> 事柄なので，週末を待たねばならず，リプライが遅れました。ご了解ください
> 。
どうぞお気になさらず。
私自身はこの現象を明確に理解できるようになればいいなあ、と思ってるだけで
す。(^^; ですから田村さんの詳細なレポートには、ただただ感謝しております
。
本題に入る前に、田村さんのレポートのなかでちょっと気になったところ。
> 以下にその結果を報告いたしますが，その際，記述の便宜上，
> # for i in $(find /KNOPPIX -type f -links +1); do ls -li $i;
> done > hardlink_ls.list
> # wc -l hardlink_ls.list
> の結果を仮に"result1"と呼び，
> # cat hardlink_ls.list | cut -d " " -f1 | sort | uniq | wc -l
> の結果を"result2"と呼ぶことにします。
>
> まず，タイで頒布されたKNOPPIX3.2英語版（2003-07-25）のCDから
> 起動して、/KNOPPIXを/mnt/hdb1/32orig以下にコピーしました。それぞ
> れを調べると；
>
> # du -s /KNOPPIX -> 1833799
> # du -s /mnt/hdb1/32orig -> 1869462
>
> となりました。増加率は2%弱でしかありませんでした。それぞれのリンク
> の状態を調べてみると、/KNOPPIXの側では；
> result1: 26604
> result2: 7036
サイズの増加率 2% というのは置いても、result1とresult2の数値が大きく違う
のは予想外でしたので、うちでも英語版(KNOPPIX_V3.3-2004-02-16-EN)を使って
試してみました。
その結果
# for i in $(find /KNOPPIX -type f -links +1); do ls -li $i; done >
hardlink_ls.list
として作成した hardlink_ls.list の中身を見ると、行頭に空白がある行が見つ
かりました。ですから
> # cat hardlink_ls.list | cut -d " " -f1 | sort | uniq | wc -l
> の結果を"result2"と呼ぶことにします。
の部分を、
# cat hardlink_ls.list | sed 's/^ //' | cut -d " " -f1 | sort | uniq | wc -l
とすれば、ひょっとすると`result2'の数値が違ってくるかもしれません。
ところで、そんなことをやっていて気がついたんですが、ハードリンクの数が
本家版と産総研の日本語版で違うみたいですね。
本家英語版 KNOPPIX_V3.3-2003-11-19 --> 5967
日本語版 knoppix_20031119-20031219 --> 1544
その内訳を見てみると、日本語版に含まれるハードリンクは
jfbterm
kon2
ncftp
ncurses-term
というパッケージ由来のもので、それらのパッケージはは本家版には含まれて
いません。
ということは、産総研でリマスタを行なう際にも、ハードリンクの数が 0(ゼロ)
になる、という現象が起きているんだろうなと思いました。
もっとも先のメールに書いたように、/KNOPPIXにcloopファイルがマウントされた
状態であっても、ハードリンクされたファイル同士のinumberが同じになっていな
い、なんてこともあるので、ここで話題にしている「ハードリンク」を普通の
ハードリンクと考えていいのかどうか、私にはわかりませんが。
さて、ところで、以上書いてきたことは、
マウントされたcloopファイルKNOPPIXからハードディスクへ
ファイルのコピーを行なうと、ハードリンクの数が 0(ゼロ)
になってしまう。
ということであって、/KNOPPIXディレクトリ下のファイルをハードディスクに
コピーする際にファイルサイズの合計が大きく増加する現象の直接の説明には
なっていませんね。
田村さんの、
> # du -s /KNOPPIX -> 1833799
> # du -s /mnt/hdb1/32orig -> 1869462
を目にして、ちょっと思いついて KNOPPIX_V3.3-2004-02-16-ENで確かめてみた
んですが、
# for i in $(find /KNOPPIX -type f -links +1); do ls -li $i; done | \
sed 's/^ //' > hardlink_ls.list
# cat hardlink.list | awk '{ x += $6 } ;END { print "total size: " x "
(bytes)" }'
total size: 46335542 (bytes)
ということは、lsコマンドでリンクの数が2以上であるファイルのサイズを
すべて合計しても、たかだか 45MB程度だということですね。
(重複して計上してるので実際のサイズはさらに小さくなるはず)
私のうちでは今日も(^^;
1847310 ---> 2125408
増分 278098 (kilobytes) 15% up
でした(関係ないでしょうけどコピー先はext3です)。
ですから、ハードリンクのことだけでは、270MBものサイズ増加を説明
できないことは明らかですね。
> す。しかし，今回の私の実験では，容量の増加率は2%弱と微々たるもので
> したが，柘植さんの実験では15%弱も増加しています。こんな大きな差が
> 生じるには，何か別の原因があるのではないかと，私は疑っています。私
私も同様な考えに変わってきました。
> が[knoppix:2912]で報告した事例では，おそらく20%以上も増加していた
> ものと想像します。柘植さんの報告事例は，これはもう半ば「悲劇の再現」
> ではなかったのでしょうか。
そして「悲劇」は今日もまた続いております(^^;
うちでは、違うバージョンで5回試みて5回とも15%増という結果になりました。
> これだけでしたら，あまり問題にならないのかもしれません。ところが，
> 偶発的にこの増加率が15%や20%などと，一桁高くなる場合があるので
> はないでしょうか。ポップコーンが弾けるようにです。またまた，振出し
> に戻ってしまったようですが，これ以上，どのようにその原因を追究した
> ら良いのか，私には分かりませんので，どなたか、妙案をお持ちの方がい
> らっしゃったら、ご教示いただきたいと存じます。
これも田村さんに同じ、です。
私にあと思いつくのは、コピー先の fs type や block sizeを変えてみたら
どうなるだろう、ということくらい。
> いずれにいたしましても，リマスタを目指す場合に，できればKnopperさん
> ご自身が配付するオリジナルか，あるいはそれに基づく第一次リマスタ版
> を使用するように努め，孫，ひ孫，玄孫など，多重派生版を使用すること
> は控えた方が良い，ということだけは確実に言えるように思えます。
これについては、私にはよくわかりません。
子、孫、ひ孫とサイズが大きくなってゆくということは、おもしろいけど、
ちょっと想像できないような気がするし。;-p
でも、私はこの現象を理解できてるわけじゃないので、もしかしたら田村さん
のおっしゃるとおりなのかもしれませんね。
--
Tsuge Akihide
|
