タイ，ノンタブリ県の田村です。
「リマスタ時の奇怪現象」に関してですが，何せ実験にたいへん時間がかかる
事柄なので，週末を待たねばならず，リプライが遅れました。ご了解ください。
[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/
| 