タイ，ノンタブリ県の田村です。
[knoppix:3005]でこれまでの状況を柘植さんにまとめていただきました。
本来なら私がするべきことですが，先輩の手を煩わせる結果となりまし
た。恐縮いたしております。
まず[knoppix:3004]へのご返答から始めます：
On 2004.2.23, at 01:07 PM, Tsuge Akihide wrote:
私が住んでいるところでは今朝から吹雪模様です、いや地球は広い。
タイの人々は寒さの辛さを知りませんから，皆うらやましがりますよ。
当地は正真正銘の熱帯。7月にもなれば，太陽は天中を超えて北側に傾き，
バナナ，パパイヤ，椰子の木がそこら中にニョキニョキと育つ土地柄です。
困るのは毒蛇。庭先にコブラが出ます。子供たちは絶対に草むらに足を踏
み入れません。暑いからと言って，小川に入って遊ぶのも危険。コブラは
泳ぎの達人です。
それはさておき，
ずいぶん昔にフォーマットしたHDみたいですね。
最近のmke2fsでext2ファイルシステムを作ると、デフォルトで
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
こうなります。
でもこのへんは本スレッドで問題にしていた現象とは関係ないでしょうね。
ええ，実はこれ、Linux上でフォーマットしたものではないんです。私は
昔からパーティションに関してはPartitionMagicのファンで，今でもV.6を
利用しています。その後，必要を感じなかったので，バージョンアップし
ていません。しかし，このパーティションを作成した時期自体はつい最近，
１か月ほど前だと思います。PartitionMagic6でext2を作成すると，block
sizeは1024 bytesになります。ですから，私が普段利用しているLinux用の
パーティションは全て，block size: 1024です。
# Default mount options: (none)
# Filesystem state: not clean
これもまた問題の現象とは関係ないでしょうけど、
`not clean' てのがちょっと気になりますね。
fsckが走ったあとでも`not clean'のままなんでしょうか。
これはおそらく，/dev/hdb1をマウントしたまま，tune2fsを走らせたから
だと思います。その後，パーティションを作り直し，mke2fs 1.34-WIP
(21-May-2003)でフォーマットし直しても，マウントした状態でtune2fsを
適用すると，”not clean"となりました。マウントを解除すると、"clean"と
なりました。
# Errors behavior: Continue
# Filesystem OS type: Linux
# Inode count: 1155072
# Block count: 4618656
1 inode 当たり 4 KB ってことですね。
# Reserved block count: 184746
# Free blocks: 2592174
# Free inodes: 1020039
# First block: 1
# Block size: 1024
田村さんのところでサイズの増加が少ない原因はこれでしょうね。
デフォルトだと4096になります。
うちで確認したところ、フォーマットの際にブロックサイズを変えること
によってコピー前後のファイルサイズ合計は以下のように変化します。
[ext2, ブロックサイズ 4096]
1847310 ---> 2125424
増分 278114(kilobytes) 15% up
[ext2, ブロックサイズ 2048]
1847310 ---> 1952938
増分 105628(kilobytes) 5.7% up
[ext2, ブロックサイズ 1024]
1847310 ---> 1877319
増分 30009(kilobytes) 1.6% up
<...>
上記の結果から
/dev/hdb1を オプションなしでフォーマット(mke2fs /dev/hdb1)
した上でコピーしてみたら、きっと2GB以上になると思いますよ。
私も今朝，/dev/hdbを全て初期化し，hdb1, hdb5, hdb6に分割して，それ
ぞれのblock sizeを1024, 2048, 4096に設定し，それぞれに/KNOPPIX
(V.3.2 2003-07-25-EN)をコピーしてみました。"du -s"の結果は：
/KNOPPIX --> 1838799
/mnt/hdb1/32orig --> 1869464 ( 1.6%増)
/mnt/hdb5/32orig --> 1949910 ( 6.0% 増)
/mnt/hdb6/32orig --> 2127960 (15.7% 増)
新しいHDDのほうは、きっとブロックサイズが4096なのでしょうね。
楯突くようで恐縮ですが，否です。masterの方もPartitionMagic6で作りま
したから，全て1024です。私が経験した「奇怪現象」はblock size: 1024上
で生じたものです。その後，masterの方のパーティションは再初期化して
いません。当時のままです。
と言うことは、私の立場から申せば，柘植さんが毎日ご経験なさっている
増量現象は，やはり「真性の奇怪現象」ではないということになります。
なんだか「幻の奇怪現象」になってきました。
このブロックサイズの件に関しては、根本的な疑問があります。mkisofs
で生成されるcloopファイルには，勿論ブロックサイズと言う概念はあり
ませんよね。上記KNOPPIXオリジナル版で起動した場合と，私がblock size:
1024上で作ったリマスタ版の場合とを比べてみましたが，マウントされた
/KNOPPIX/etcのファイルサイズでは，大きな違いはありませんでした。
そこで，上記hdb1, hdb5, hdb6にコピーしたKNOPPIXから、リマスタせ
ずにcloopファイルを生成して，その容量の差を調べてみようと思います。
果たして私が経験したような肥大化が発生するかどうか。もし発生すれば，
block sizeが原因だったかもしれません。もし発生しなければ，原因は何か
別のところにあるかもしれません。
ところで，これまで私は柘植さんお一人と対話して参りました。多岐にわ
たる有益なアドバイスをいただき，柘植さんには深く感謝いたしておりま
すが，これ以上，このテーマでMLのメンバーの皆様に退屈な思いを強いる
ことは心苦しい限りです。[knoppix:3005]で柘植さんがこれまでの経過を
まとめてくださいましたので，このスレッドはひとまず終了にいたしては
いかがでしょうか。私は，これからもこの現象に関してできる限り調べて
みるつもりであり，もしMLメンバーの皆様にご報告する価値のある新事実
が判明した際には，改めてお伝えする，という所存です。ご了承いただけ
れば幸いです。
田村志緒理
__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/
| 