次のページ 前のページ 目次へ

14. 問題の解決

問題を抱えたと思う人の多くは、しかし実際には何も悪い点はありません。 また、抱えている問題の原因がディスクのジオメトリにあると思われる場合でも、 実際にはディスクのジオメトリには何の問題もありません。 上で述べたようなすべてのことが事態を複雑にしていますが、 ディスクのジオメトリの扱いは非常に簡単です: まったく申し分なければ何もする必要はありません; もし起動時に `LI' の先に進まない場合は LILO にキーワード `linear' を与えてください。 カーネルの起動メッセージを見て思い出してください: (LILO や fdisk やカーネルコマンドラインでヘッド数やシリンダ数を 与えて)ジオメトリをいじくればいじくるほど、 正常には動作しなくなるでしょう。おおざっぱにいえば、デフォルトが一番なのです。

さらに思い出してください: Linux がディスクのジオメトリを使わない所、 つまりLinux が動作している間は、 ディスクのジオメトリによって問題が引き起こされることはありません。 それどころか、ディスクのジオメトリは LILO と fdisk だけに使用されます。 そう、LILO がカーネルの起動に失敗する場合は、 ジオメトリに問題があるかもしれません。 異なる OS がパーティションテーブルを理解しない場合は、 ジオメトリに問題があるかもしれません。でもそれだけです。 とりわけ、mount が動作しないように思える場合でも、 ディスクのジオメトリには何の関係もありません - 問題は他の所にあります。

14.1 問題: SCSI から起動した時、IDE ディスクが変なジオメトリを持っている

ディスクが変なジオメトリを持つのはとてもありがちです。 Linux カーネルは hd0 と hd1 (80H と 81H の数字がふられた BIOS ドライブ) について BIOS に問い合わせ、 このデータが hda と hdb のものだと仮定します。 しかし SCSI から起動したシステム上では、 最初の二つのディスクが SCSI ディスクでしょうから、 最初の IDE ディスク hda である 5番目のディスクに対して sda のジオメトリが割り当てられるなんてことが起きるかもしれません。 これは、起動時や /etc/lilo.conf において、適切な数字 C, H, S を使って ブートパラメータ `hda=C,H,S' を与えることで簡単に解決できます。

14.2 問題なし: 同じディスクが異なるジオメトリを持っている?

「私はまったく同じ IBM 製のディスクを 2台持っています。 しかし、fdisk が表示するサイズは異なっています。こんな感じ: 

# fdisk -l /dev/hdb
Disk /dev/hdb: 255 heads, 63 sectors, 1232 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot  Start      End   Blocks   Id  System
/dev/hdb1           1     1232  9896008+  83  Linux native
# fdisk -l /dev/hdd
Disk /dev/hdd: 16 heads, 63 sectors, 19650 cylinders
Units = cylinders of 1008 * 512 bytes

   Device Boot  Start      End   Blocks   Id  System
/dev/hdd1           1    19650  9903568+  83  Linux native
何ででしょ?」

何が起きているのでしょう? そう、まず第一に、これらのドライブはしっかり 10 ギガバイト使えています: hdb は 255*63*1232*512 = 10133544960 バイトで、 hdd は 16*63*19650*512 = 10141286400 バイトですが、 何も悪い所はないしカーネルはどちらも 10.1 GB であると理解しています。 では何故サイズが違うのでしょう? それは、カーネルは最初の二台の IDE ディスクについては BIOS から情報を得、 その BIOS は hdb を 255 ヘッドで再マップしているからです (16*19650/255=1232 シリンダ)。 この丸めによる損失は 8MB 弱です。

hdd も同じ方法で再マップしたいのならば、 カーネルのブートパラメータに `hdd=1232,255,63' を与えてください。

14.3 問題なし: df より fdisk の方がパーティションが大きく見える

fdisk はブロックがディスク上にいくつ存在するかを報告します。 mke2fs を使ってディスク上にファイルシステムを作った場合、 ファイルシステムは簿記(bookkeeping)のためのいくらかのスペースを必要とします - 通常はファイルシステムのサイズの 4% くらいで、 mke2fs する際に多くの inode を作るとより増えます。 以下は例です: 

# sfdisk -s /dev/hda9
4095976
# mke2fs -i 1024 /dev/hda9
mke2fs 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
...
204798 blocks (5.00%) reserved for the super user
...
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda9            3574475      13  3369664      0%   /mnt
# df -i /somewhere
Filesystem           Inodes   IUsed   IFree  %IUsed Mounted on
/dev/hda9            4096000      11 4095989     0%  /mnt
#
まず、4095976 ブロックのパーティションがあります。 ここに ext2 ファイルシステムを作成し、適当な所にマウントします。 すると 3574475 ブロックになってしまいます - 521501 ブロック (12%) は inode と他の簿記用スペースに消費されたのです。 合計 3574475 と 3369664 の間の差は、ユーザが 13 ブロックを使用していて、 さらに 204798 ブロックが root のために予約されているためであることに 注意してください。 後者は tune2fs で変更できます。 この `-i 1024' はニューススプールなどの小さいファイルが山ほどある 場合にのみ適しています。 デフォルトではこうなります: 
# mke2fs /dev/hda9
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda9            3958475      13  3753664      0%   /mnt
# df -i /somewhere
Filesystem           Inodes   IUsed   IFree  %IUsed Mounted on
/dev/hda9            1024000      11 1023989     0%  /mnt
#
今度は 137501 ブロック(3.3%)のみが inode のために使用され、 その結果以前より 384 MB も増えてます。 (inode 1つにつき 128 バイト使ってるみたいです。) 一方、先の場合では 4096000 ファイル保存できるのに対し(どう見ても多すぎ)、 このファイルシステムでは最大 1024000 ファイルが保存できます (これでも十分すぎます)。

次のページ 前のページ 目次へ
[