タイ国ノンタブリ県の田村です。
ところで、参考までに教えていただきたいのですが、
も繰り返した後で，ファイルの断片化が心配されたため，それを解消しよ
うと思い，/mnt/hda11/<resource>を空の/mnt/hdb1/に一気に移転した時に
発生した模様です。こうした作業は普段はredhat9上のconsoleで行ってい
ここで「移転」した際の具体的なコマンドはどんなものだったのでしょうか。
私が見落としているのかも知れませんが、godber さんの投稿にも
[OUTLINE]
I pull the contents of the CDROM to harddisk
I pull the contents of the compressed loopback FS to harddisk
I do NOTHING ... add nothing, change nothing
とあるだけで、具体的な方法については触れられていなかったので、
ちょっと気になりました。
はい、私の場合はごく単純な"mv"です。私は１つの版のリマスタに３つの
パーティションを使っています；作業用（例えば/mnt/hda11），デフラグ用
（同じく/mnt/hda12）、CDイメージ用（同じく/mnt/hda13）。CD起動の
状態から、「教科書通り」に/KNOPPIX以下を/mnt/hda11にコピーし、リマ
スタ作業が完成した時点で，これをデフラク用に用意したパーティションに
一旦，移転します；
mv /mnt/hda11/src32 /mnt/hda12/
そして、/mnt/hda12からdestinationを/mnt/hda13に指定して圧縮KNOPPIX
イメージを作成します。ただ単に断片化によるスピードの低下を防ぐ目的で
の作業に過ぎません。
こんな面倒なことを始めたのも，どこかで「リマスタすると、必ずオリジナ
ルよりスピードが落ちる。オリジナルは最適化されているからだ」といった
記述を読んだことがあったからです。それに加えて，例のgodber氏の投稿を
読んだことも動機付けになりました。何とかイメージ・ファイルをコンパクト
にしたいと思ったのです。でも本当は、 godber氏の投稿に関しては、私の
取り違えだったのかもしれません。断片化と圧縮イメージ・ファイルの大き
さの問題は別個ですよね、よく考えてみると。
初めはこの"mv"コマンドの使用に躊躇があったんですが，マウントされた
/KNOPPIXから、任意の場所にコピーが許されるなら，それを更に任意の場所
に移動しても問題は起きないはずだと判断して，始めました。これまで何度
も繰り返し，それを基にCDも作成してきましたが，この移転が原因で問題を
起こしたことは，これまで一度もありませんでした。今回の奇怪現象は、た
またま/mnt/hda11/src32を、"mv"コマンドを使って/mnt/hdb1に移転した時に
起きてしまったらしいのです。一言付け加えますと，この容量巨大化を起こ
したsrc32を基にしてCDイメージを作成してみたところ，702MBとなりまし
た。ぎりぎりでCDに焼くことができたので，試しに起動してみたところ，
全く正常に稼働しました。
前回の報告でも触れましたように，その後，同様の手続きでsrc32を色々な場
所に移動してみたのですが，これまでのところ「悲劇の再現」は果たしており
ません。
以上，追加説明かねがねお答えいたします。
田村志緒理
__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/
| 