Vitruvian Penguin
knoppix

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

Date: Mon, 23 Feb 2004 15:07:07 +0900
X-mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu)
柘植です。こんにちは。

田村さんには長いあいだお付き合いいただいて感謝してます。
ある程度データが揃ってきたので、そろそろここらで問題を
整理してこのスレッドにもけりをつけることにしましょうか。

On Mon, 23 Feb 2004 00:01:36 +0700
[knoppix:2997] Re: リマスタ時の奇怪現象
Shiori Tamura <shiori_tamura@xxxxxxxxxxx> wrote:

> 当地ではいよいよ酷暑の季節が始まりました。週末,節電のためエアコンなしの
> 仕事部屋で、オーバーヒートを心配しながらコンピュータの前に座っていること
> はかなり苦痛になりましたが,スレッドのリズムを崩しては申し訳ありませんの
> で,現時点でお答えできることだけは,お伝えいたそうと存じます:

私が住んでいるところでは今朝から吹雪模様です、いや地球は広い。

さて、本題に入る前に

> KNOPPIX 3.2 (2003-07-25)を起動して,もう一度調べてみたのですが,

 [...snip...]

>     # for i in $(find /KNOPPIX -type f -links +1); do ls -li $i; done > 
> hardlink_ls.list
>     # wc -l hardlink_ls.list
>     # 6651
> 
>     # cat hardlink_ls.list | cut -d " " -f1 | sort | uniq | wc -l
>     # 6651

たぶんこれがmkisofsで作成されたISO9660ファイルシステムでの標準的な
状態なんでしょうね。本来ならハードリンクされたファイル同士は同じ
inode番号を持つはずなのに、ISO9660ファイルシステム上ではinode番号
がそれぞれ別々になってしまうんでしょう。このことについては後でまた
触れます。

> >>    # du -s /KNOPPIX                ->      1833799
> >>    # du -s /mnt/hdb1/32orig        ->      1869462
> >
> > という結果が出たときの `tune2fs -l /dev/hdb1' の出力が見てみたい
> > のですが、急ぎませんので、よろしければ教えていただけませんでしょうか。
> 
> はい,その結果:
> 
>     # tune2fs 1.34-WIP (21-May-2003)
>     # Filesystem volume name:   <none>
>     # Last mounted on:          <not available>
>     # Filesystem UUID:          <none>
>     # Filesystem magic number:  0xEF53
>     # Filesystem revision #:    0 (original)
>     # Filesystem features:      (none)

ずいぶん昔にフォーマットしたHDみたいですね。
最近のmke2fsでext2ファイルシステムを作ると、デフォルトで

  Filesystem revision #:    1 (dynamic)
  Filesystem features:      filetype sparse_super

こうなります。
でもこのへんは本スレッドで問題にしていた現象とは関係ないでしょうね。

>     # Default mount options:    (none)
>     # Filesystem state:         not clean

これもまた問題の現象とは関係ないでしょうけど、
`not clean' てのがちょっと気になりますね。
fsckが走ったあとでも`not 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

> と出ました。私もあれから,何度か/KNOPPIXのコピーを試してはいる
> のですが、なかなか「期待したような」結果になりません。最近では,
> やはりハードウエアが関連しているのではないかという最初の疑念に
> 戻っています。

上記の結果から

/dev/hdb1を オプションなしでフォーマット(mke2fs /dev/hdb1)
した上でコピーしてみたら、きっと2GB以上になると思いますよ。

> を覚えているからです。当初は2.2~3GBだと思い込んでいました。後に
> なって本当は1.7~8GBであることが分かったのですが,なぜそう思い込
> んだかと言うと,おそらくあの時にハードディスクにコピーした
> /mnt/hda11/src32の容量が,それ位の数字を示していたからだと推測す
> るのです。この時のコピー自体はリマスタに失敗したため削除してしま
> い、今では残っていませんが,それは古いハードディスクではなく,比
> 較的新しいATA100の方でした。今後は,こちらのmasterに的を絞って,

新しいHDDのほうは、きっとブロックサイズが4096なのでしょうね。

  # tune2fs -l /dev/hda11 | grep '^Block size'

で確認してみてはいかがでしょう。

さて、本題に入ろうかと思ったのですが、ちょいとこのメールも
長くなったので、本スレッドのまとめは別便で送ることにします。

-- 
Tsuge Akihide
<Prev in Thread] Current Thread [Next in Thread>