[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[knoppix:2958] Re: リマスタ時の奇怪現象

タイ，ノンタブリ県の田村です。

「リマスタ時の奇怪現象」に関してですが，何せ実験にたいへん時間がかかる
事柄なので，週末を待たねばならず，リプライが遅れました。ご了解ください。

[knoppix:2921]で柘植さんは，次のようにお書きになっています：

> そこでknoppix_20031119-20040202を使って試してみました。
>
> CD起動したknoppix_20031119-20040202上で、/KNOPPIXディレクトリの内容を
> 調べてみます。
>
> # for i in $(find /KNOPPIX -type f -links +1); do ls -li $i; done > > hardlink_ls.list
> # wc -l hardlink_ls.list
> 1544
> # cat hardlink_ls.list | cut -d " " -f1 | sort | uniq | wc -l
> 1544
>
> ということは、ハードリンクされているファイルの数は 1544 個らしいのですが、
> inode番号が同じものがひとつも存在していない、ということなんだと思います。
> また、/KNOPPIXディレクトリのサイズは
>
> # du -s /KNOPPIX
> 1769084 /KNOPPIX
>
> となっています。
>
> さて、この/KNOPPIXディレクトリの中身をHD上のディレクトリにコピー
> してみます。
>
> # cp -a /KNOPPIX/* /mnt/hda5/Knoppix.source
> # find /mnt/hda11/Knoppix.source -type f -links +1 > hardlink.list
> # ls -l hardlink.list
> -rw-r--r-- 1 root root 0 2004-02-09 16:04 > hardlink.list
>
> ハードリンクの数が0になりました。また、サイズも
>
> # du -s /mnt/hda5/Knoppix.source
> 2031108 /mnt/hda5/Knoppix.source
>
> と 262024(kilobytes) も大きくなりました。

お教えいただいたコマンドを使わせていただき，私も実験してみました。
以下にその結果を報告いたしますが，その際，記述の便宜上，
# 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

となっています。しかし，/mnt/hdb1/32origの側では；
result1: 0

となりました。柘植さんもおっしゃる通り，/KNOPPIX以下をHDにコピー
したそれだけで，ハードリンクそれ自体はなくなってしまうもののようで
す。しかし，今回の私の実験では，容量の増加率は2%弱と微々たるもので
したが，柘植さんの実験では15%弱も増加しています。こんな大きな差が
生じるには，何か別の原因があるのではないかと，私は疑っています。私
が[knoppix:2912]で報告した事例では，おそらく20%以上も増加していた
ものと想像します。柘植さんの報告事例は，これはもう半ば「悲劇の再現」
ではなかったのでしょうか。

ともあれ，更に実験を続けました。[knoppix:2912]でご報告したように，
例の悲劇の後，freedups.plを/lib, /usrに適用した結果，2,354,543,472 bytes
に膨れ上がっていた容量は，1,817,705,855 bytesにまで収縮しました（な
お，この両数値は，"du -s"で調べたのではなく，konqueror上のプロパティ
で表示された結果です）。このfreedups処理をかけた後のリンクの状況を
調べてみると；
# du -s /mnt/hda15/32rmst -> 1793276
result1: 25782
result2: 4742

と出ます。そして、これを基にして作成したRemastered-CDから起動し，
/KNOPPIXを調べてみると；
# du -s /KNOPPIX -> 1821232
result1: 4297
result2: 4297

となります。容量では約1.6%の増加です。ハードリンクに関しては，柘植
さんがknoppix_20031119-20040202でお調べになったのと同様の結果となっ
ています。

以上の結果を総合すると，ハードリンクの不認識は、iso9660ファイルを
マウントして元のファイルを還元する時に留まらず，そもそもiso9660ファ
イルを作成する段階で既に発生している、と言えるのではないでしょうか。
しかし，それに伴う容量の増加は，通常1.5~2%に収まっているようです。

これだけでしたら，あまり問題にならないのかもしれません。ところが，
偶発的にこの増加率が15%や20%などと，一桁高くなる場合があるので
はないでしょうか。ポップコーンが弾けるようにです。またまた，振出し
に戻ってしまったようですが，これ以上，どのようにその原因を追究した
ら良いのか，私には分かりませんので，どなたか、妙案をお持ちの方がい
らっしゃったら、ご教示いただきたいと存じます。

いずれにいたしましても，リマスタを目指す場合に，できればKnopperさん
ご自身が配付するオリジナルか，あるいはそれに基づく第一次リマスタ版
を使用するように努め，孫，ひ孫，玄孫など，多重派生版を使用すること
は控えた方が良い，ということだけは確実に言えるように思えます。

> この「最適化」については
>
> [debian-knoppix] Klaus's latest build scripts
> http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-April/ > 002595.html
>
> にあるKnoppix.mksortlistを使うとよいらしい、ですね。

このファイルを見てみました。正直に申して，私にはこれを正確に理解
するだけの知識が欠けていますので，使用は差しひかえたいと存じます。
ただ，mkisofsを実行する時に，予想通り，細かくダイレクトリ毎に分け，
しかも，起動スピードを最適化するためでしょう，それを読み込みの順
番に従って書き込んでいるらしい、という点が確認できました。それが
分かっただけでも収穫でした。ありがとうございました。

それから，これはあまり益のない質問かもしれませんが，上記の報告に
も現れているように、ダイレクトリの容量を調べる際，"du -s"で返される
値（単位はkilobyte）と，konquerorのプロパティで表示される値（単位は
byte）とが一致しないのはなぜなのでしょうか。どちらを信じて良いのか，
いつも迷ってしまいます。

以上，「奇怪現象」のその後について、ご報告いたします。

田村志緒理

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/


--[PR]------------------------------------------------------------------
　　　　● 話題の【スパイダーマン】の複製シルクスクリーンがあたる!!
　　　　　　 ☆手がけたのはあの世界の『 横尾忠則 』☆
　　　―――――― 世界で１つだけのキャンペーン!! ――――――
　　このチャンスを逃したらまずいぞ!!応募はこちらから ↓↓↓
　　　　　　 http://ad.freeml.com/cgi-bin/ad.cgi?id=c5tqI
------------------------------------------------------------------[PR]--
<GMO GROUP> Global Media Online www.gmo.jp