■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
HOWTO: Multi Disk System Tuning
Stein Gjoen, sgjoen@nyx.net
v0.33a, 20 May 2002
中野武雄 nakano@apm.seikei.ac.jp
v0.33aj1, 16 November 2002
この文書は Linux システムで複数のディスクやパーティションを最適に運用
するための方法について述べたものです。この文書の一部の話題は Linux に
特有のものですが、用いているアプローチは一般的なものですから、他の様々
なマルチタスク OS にも適用できます。
______________________________________________________________________
目次
1. はじめに
1.1 Copyright
1.2 免責
1.3 新着情報
1.4 謝辞
1.5 翻訳
2. ディスクデバイスの論理構造とこの文書の構成
2.1 ディスクの論理的構造
2.2 文書の構成
2.3 リーダースガイド
3. ドライブの技術
3.1 ドライブ
3.2 ジオメトリ
3.3 メディア
3.3.1 磁気ディスク
3.3.2 光ディスク
3.3.3 固体素子ディスク
3.4 インターフェース
3.4.1 MFM と RLL
3.4.2 ESDI
3.4.3 IDE と ATA
3.4.4 EIDE, Fast-ATA, ATA-2
3.4.5 Ultra-ATA
3.4.6 Serial-ATA
3.4.7 ATAPI
3.4.8 SCSI
3.5 配線
3.6 ホストアダプタ
3.7 マルチチャンネルシステム
3.8 マルチボードシステム
3.9 速度比較
3.9.1 コントローラ
3.9.2 バスの形式
3.10 ベンチマーク
3.11 比較検討
3.12 将来の開発予定
3.13 お薦め
4. ファイルシステムの構造
4.1 ファイルシステムの特徴
4.1.1 スワップ領域
4.1.2 一時記憶領域 (/tmp と /var/tmp)
4.1.3 スプール領域 (/var/spool/news と /var/spool/mail)
4.1.4 ホームディレクトリ (/home)
4.1.5 バイナリ (/usr/bin と /usr/local/bin)
4.1.6 ライブラリ (/usr/lib と /usr/local/lib)
4.1.7 Boot
4.1.8 ルートファイルシステム
4.1.9 DOS など
4.2 用語の説明
4.2.1 速度
4.2.2 信頼性
4.2.3 ファイル
5. いろいろなファイルシステム
5.1 汎用のファイルシステム
5.1.1 minix
5.1.2 xiafs と extfs
5.1.3 ext2fs
5.1.4 ext3fs
5.1.5 ufs
5.1.6 efs
5.1.7 XFS
5.1.8 reiserfs
5.1.9 enh-fs
5.1.10 Tux2 fs
5.2 Microsoft のファイルシステム
5.2.1 fat
5.2.2 fat32
5.2.3 vfat
5.2.4 ntfs
5.3 Logging ファイルシステム・ Journaling ファイルシステム
5.4 リードオンリーのファイルシステム
5.4.1 High Sierra
5.4.2 iso9660
5.4.3 Rock Ridge
5.4.4 Joliet
5.4.5 閑話
5.4.6 UDF
5.5 ネットワークファイルシステム
5.5.1 NFS
5.5.2 AFS
5.5.3 Coda
5.5.4 nbd
5.5.5 enbd
5.5.6 GFS
5.6 特殊なファイルシステム
5.6.1 tmpfs と swapfs
5.6.2 userfs
5.6.3 devfs
5.6.4 smugfs
5.7 ファイルシステムのお勧め
6. ディスク関連技術
6.1 RAID
6.1.1 SCSI-to-SCSI
6.1.2 PCI-to-SCSI
6.1.3 ソフトウェア RAID
6.1.4 RAID のレベル
6.2 ボリューム管理
6.3 Linux md カーネルパッチ
6.4 圧縮
6.5 ACL
6.6 cachefs
6.7 透過 (Translucent) ファイルシステム・継承 (Inheriting) ファイルシステム
6.8 トラックの物理的配置
6.8.1 ディスクの速度値
6.9 Yoke
6.10 組み合わせ
6.11 お勧め
7. 他のオペレーティングシステム
7.1 DOS
7.2 Windows
7.3 OS/2
7.4 NT
7.5 Windows 2000
7.6 Sun OS
7.6.1 Sun OS 4
7.6.2 Sun OS 5 (Solaris)
7.7 BeOS
8. システムのクラスタ化
9. マウントポイント
10. 考察と配置
10.1 自宅のシステム
10.2 各種サーバ
10.2.1 ホームディレクトリ
10.2.2 アノニマス FTP
10.2.3 WWW
10.2.4 メール
10.2.5 ニュース
10.2.6 その他
10.2.7 サーバ向けのお勧め
10.3 落とし穴
11. ディスクのレイアウト
11.1 パーティションの選択
11.2 パーティションとドライブのマッピング
11.3 ドライブ上でパーティションを並べ替える
11.4 最適化
11.4.1 特性による最適化
11.4.2 ドライブの並列化による最適化
11.5 妥協的手法
12. パーティション分割の実作業
12.1 チェックリスト
12.2 ドライブとパーティション
12.3 パーティション分割
12.4 再パーティション
12.5 Microsoft パーティションのバグ
12.6 複数デバイスの一括利用 (md: Multiple Devices)
12.7 フォーマット
12.8 マウント
12.9 fstab
12.10 マウントオプション
12.11 お勧め
13. メンテナンス
13.1 バックアップ
13.2 デフラグメント
13.3 不要ファイルの削除
13.4 システムのアップグレード
13.5 復旧
13.6 レスキューディスク
14. 上級者向け情報
14.1 ハードディスクのチューニング
14.2 ファイルシステムのチューニング
14.3 スピンドルを同期させる
15. トラブルシュート
15.1 インストール中
15.1.1 ディスクの配置
15.1.2 フォーマット
15.2 ブート中
15.2.1 ブートに失敗する
15.2.2 シングルユーザーモードになる。
15.3 動作中
15.3.1 スワップ
15.3.2 パーティション
16. この文書以外の情報
16.1 ニュースグループ
16.2 メーリングリスト
16.3 HOWTO
16.4 Mini-HOWTO
16.5 ローカルな情報源
16.6 Web ページ
16.7 検索エンジン
17. 助けを求めるには
18. 終わりに
18.1 今後の予定
18.2 情報募集
18.3 著者が提案するプロジェクト
19. Q & A
20. 補遺
20.1 スワップパーティション: 使うべきか使わざるべきか？
20.2 マウントポイントと /mnt
20.3 電力と発熱
20.4 Deja
20.5 クラッシュリカバリ
21. 付録 A: パーティション配置表: マウントとリンク
22. 付録 B: パーティション配置表: 番号付けと容量の割り振り
23. 付録 C: パーティション配置表: パーティションの作成
24. 付録 D: 例 1: 多目的サーバ
25. 付録 E: 例 1: マウントとリンク
26. 付録 F: 例 1: 番号付けと容量の割り振り
27. 付録 G: 例 1: パーティションの作成
28. 付録 H: 例 2
29. 付録 I: 例 3: SPARC Solaris
30. 付録 J: 例 4: ドライブ 4 台のサーバ
31. 付録 K: 例 5: ドライブ 2 台のシステム
32. 付録 L: 例 6: ドライブ 1 台のシステム
33. 付録 M: ディスクシステム記述スクリプト
______________________________________________________________________
1. はじめに
理由はないしょですが、この最新版を Taylor3 版と呼ぶことにしたいと思い
ます。
新たなコードネームは工業規格に則り、この文書の現状を示すものです。
この文書を書いた理由は 2 つあります。ひとつめは、筆者が 3 台の古い
SCSIディスクを使って Linux システムを立ちあげたとき、どのように使うの
がベストであるかを試行錯誤したためです。もうひとつは、文書を書く人はご
ほうびがもらえると聞いたからです...
この文書は Linux Filesystem Structure Standard (FSSTND) と一緒に読んで
もらうことを念頭において書きました。もちろん FSSTND にとって代わろうと
するつもりはありません。 FSSTND に現れるディレクトリを物理的にどう振り
分けるかについての提案をしようというものです。ドライブ、パーティショ
ン、型式、RAID、ファイルシステム、容量といったパラメータに関して考察
し、自宅で使うシステムから大規模なインターネットサーバに至る各種の
Linux システムにおいて、これらをどう扱い、どう最適化するかについて述べ
ます。
FSSTND の後継版は Filesystem Hierarchy Standard という名前になり、
Linux 以外もカバーしています。すでに FHS 2.0, 2.1, 2.2 がリリースされ
ていますが、まだやらなければならない部分が少々残っています。今では最近
のディストリビューションの多くは、 FHS に準拠することを目指していま
す。
Linux インストールガイドの類をよく読んでおくのも良い考えです。 PC のシ
ステムを使っている方 (ほとんどでしょ？) は comp.sys.ibm.pc.hardware
ニュースグループの FAQ を読めば、特に記憶メディアに関して有益な情報が
得られるでしょう。
この文書を書くことは筆者自身の学習でもあります。筆者はこの文書を、もっ
と内容が豊富でもっと正確なものに発展させたいと考えています。
まず最初に法的な面に関する記述を少々。最近この文書も大きくなってきたの
で、このような記述が必要になってきました。
1.1. Copyright
This document is Copyright 1996 Stein Gjoen. Permission is granted to
copy, distribute and/or modify this document under the terms of the
GNU Free Documentation License, Version 1.1 or any later version
published by the Free Software Foundation with no Invariant Sections,
no Front-Cover Texts, and no Back-Cover Texts.
If you have any questions, please contact <{linux-
howto@metalab.unc.edu}>
日本語訳：
この文書の著作権は (C) 1996 Stein Gjoen が保有しています。この文書の複
写・配布・修正にあたっては、 Free Software Foundation から出版されてい
る GNU Free Documentation License Version 1.1 以降に従います。ただし
Invariant Section, Front-Cover Text, Back-Cover Text はいずれも無いも
のとします。
質問があったら <{linux-howto@metalab.unc.edu}> まで連絡してください。
訳注: 日本語訳の著作権は (C) 1996 中野武雄が保有しています。この翻訳も
同じく GFDL Version 1.1 以降に従います (Invariant Section なし、Front-
Cover Text なし、Back-Cover Text なし)。
1.2. 免責
Use the information in this document at your own risk. I disavow any
potential liability for the contents of this document. Use of the
concepts, examples, and/or other content of this document is entirely
at your own risk.
All copyrights are owned by their owners, unless specifically noted
otherwise. Use of a term in this document should not be regarded as
affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as
endorsements.
You are strongly recommended to take a backup of your system before
major installation and backups at regular intervals.
日本語訳：
この文書にある情報は、読者自身の責任の下に用いるようにしてください。こ
の文書中に存在するかもしれない誤りに関して、筆者は一切責任を持ちませ
ん。この文書の概念や例、その他いかなる内容に関しても、これを用いる際に
は読者が判断し、責任をとってください。
各著作権は特に記述がない限り、それぞれの保有者に帰するものとします。こ
の文書中における語句の引用は、その商標の範囲には抵触しないものとみなさ
れます。
インストール作業をする前にはシステムのバックアップをとっておくこと、ま
た定期的にバックアップをとり続けることを強く推奨します。
1.3. 新着情報
これは新しい著作権条項に対応したメジャーアップグレード版で、 Debian 準
拠にして彼らの配布に含めることを可能にしたものです。たくさんの間違いを
修正し、最近の ATA 機能に関する記述などの新しい話題も追加されていま
す。
開発の最前線にいる人々は、 Linux 2.4 を完成させるためにエネルギーを集
中しています。ですのでこれがリリースされるまでは Linux のディスク技術
には大きなニュースは現れないかもしれません。
この文書は PostScript でも入手できるようになりました。アメリカの
letter フォーマットとヨーロッパでの A4 フォーマットの両方を用意しまし
た。
この文書の最新バージョンの番号は、筆者の Nyx のエントリを finger
すれば、plan ファ
イルのエントリに表示されます。
またこの文書の最新バージョンは、 Nyx における筆者の Web ページでも閲覧
できるようになりました。各種フォーマットで置いてあります。
o HTML .
o プレイン ASCII テキスト (約
6200 行)
o 圧縮した PostScript ファイル (US letter フォーマット)
(約 90 ページ)
o 圧縮した PostScript ファイル (ヨーロッパの A4 フォーマット)
(約 85 ページ)
o SGML ソース (約 260 KB)
ヨーロッパにおける Multi Disk HOWTO
のミラーも登場しまし
た。
1.4. 謝辞
このバージョンでは、おかげでさらに多くの人々の貢献をいただくことができ
ました。ここに記して感謝します。
ronnej (at ) ucs.orst.edu
cm (at) kukuruz.ping.at
armbru (at) pond.sub.org
R.P.Blake (at) open.ac.uk
neuffer (at) goofy.zdv.Uni-Mainz.de
sjmudd (at) redestb.es
nat (at) nataa.fr.eu.org
sundbyk (at) oslo.geco-prakla.slb.com
ggjoeen (at) online.no
mike (at) i-Connect.Net
roth (at) uiuc.edu
phall (at) ilap.com
szaka (at) mirror.cc.u-szeged.hu
CMckeon (at) swcp.com
kris (at) koentopp.de
edick (at) idcomm.com
pot (at) fly.cnuce.cnr.it
earl (at) sbox.tu-graz.ac.at
ebacon (at) oanet.com
vax (at) linkdead.paranoia.com
tschenk (at) theoffice.net
pjfarley (at) dorsai.org
jean (at) stat.ubc.ca
johnf (at) whitsunday.net.au
clasen (at) unidui.uni-duisburg.de
eeslgw (at) ee.surrey.asc.uk
adam (at) onshore.com
anikolae (at) wega-fddi2.rz.uni-ulm.de
cjaeger (at) dwave.net
eperezte (at) c2i.net
yesteven (at) ms2.hinet.net
cj (at) samurajdata.se
tbotond (at) netx.hu
russel (at) coker.com.au
lars (at) iar.se
GALLAGS3 (at) labs.wyeth.com
morimoto (at) xantia.citroen.org
shulegaa (at) gatekeeper.txl.com
roman.legat (at) stud.uni-hannover.de
ahamish (at) hicks.alien.usr.com
hduff2 (at) worldnet.att.net
mbaehr (at) email.archlab.tuwien.ac.at
adc (at) postoffice.utas.edu.au
pjm (at) bofh.asn.au
jochen.berg (at) ac.com
jpotts (at) us.ibm.com
jarry (at) gmx.net
LeBlanc (at) mcc.ac.uk
masy (at) webmasters.gr.jp
karlheg (at) hegbloom.net
goeran (at) uddeborg.pp.se
wgm (at) telus.net
1.5. 翻訳
日本語訳 やい
ろいろな貢献をしてくれた nakano (at) apm.seikei.ac.jp には特に感謝しま
す。彼は大学で用いているコンピュータの設定についての例も送ってくれまし
た。この設定例は文書の最後に載っています。
いまや、たくさんの新たな翻訳版が入手できるようになりました。翻訳者の皆
さんの作業と、彼らからいただいた情報とに感謝します。
o ドイツ語訳 by chewie (at)
nuernberg.netsurf.de
o スウェーデン語訳 by jonah (at)
swipnet.se
o フランス語訳 by
Patrick.Loiseleur (at) lri.fr
o 中国語訳 by yesteven (at ) ms2.hinet.net
o イタリア語訳 by bigpaul (at) flashnet.it
ICP Vortex は、彼らの様々な RAID コントローラに関して詳細な情報を送っ
てくださいました。感謝します。
DPT にも感謝します。彼らは自社のコントローラに関する文書を送って下さ
り、またその文書からの引用を許可していただきました。まだこの文書には掲
載していませんが、すでに許可はいただいています。掲載の際には引用とはっ
きりとわかるようにするつもりです。
まだ多くはありません。この文書を読んでこの文書に貢献し、是非エリートの
仲間入りをしてください。もし忘れている人がいましたら知らせてください。
訳注: 邦訳にあたっては JF メーリングリストの皆さん (水原さん・松本さ
ん・岡本さん・山下さん・大畑さん・高橋さん) に有益なご意見をいただきま
した。また長谷川さんと武井さんには校正をしていただき、たくさんのご指摘
をいただきました。ありがとうございました。
この版では付録にいくつかの表を用意してあります。この表を埋めていくこと
で、システムの設計が簡単になると思います。
どんなことでも結構ですから、ご意見がありましたら筆者の Nyx のメールア
ドレス sgjoen@nyx.net までお送りください。
では、 swap と /tmp とが、ハードディスク上でつばぜり合いをしているとこ
ろを見ることにしましょう...
2. ディスクデバイスの論理構造とこの文書の構成
この HOWTO のような文書は、学習用だけでなく技術的な参考文書として用い
られることも多いので、文書の構成を変更しました。システムの設計をする人
にとっては、デバイスの論理的な階層構造の面から記述するより、この文書の
本来の目的に沿って記述する方が有益であると考えました。とはいえ、このよ
うな階層構造 (コンピュータの分野ではあちこちに出てきます) を無視しては
この文書が成り立たないのも事実です。そこで、この節ではまず階層構造の働
きについて導入的な記述をしておきます。
この文書はすでにかなりの大部になってしまいました。しかし、この文書の内
容はすべてシステム設計をするために必要なものであり、文書がいたずらに冗
長になったわけではないと確信しています。
2.1. ディスクの論理的構造
以下の図は、それぞれの層がお互いにどのように結びついているかを示したも
のです。伝統的にはアプリケーション層を最も上、物理層を最も下に書きま
す。デバイスのコントロールに用いられる各層間の関係をここで図示しておき
ます。
___________________________________________________________
|__ ディレクトリ構造 ( /usr /tmp など) __|
|__ ファイルシステム (ext2fs, vfat など) __|
|__ ボリューム管理 (AFS) __|
|__ RAID・ディスク結合 (md) __|
|__ デバイスドライバ (SCSI, IDE など) __|
|__ コントローラ (chip, card) __|
|__ 接続 (cable, network) __|
|__ ドライブ (magnetic, optical など)__|
-----------------------------------------------------------
上図のうち「ボリューム管理」および「RAID・ディスク結合」の層は省略され
る場合もあります。下の 3 層がハードウェアとみなされます。この文書に
は、これらの各層すべてについて必要な情報が与えられています。
2.2. 文書の構成
ほとんどのユーザは手元にあるハードウェアから作業を開始するでしょうが、
目的が先にあって、システムをどの程度の大きさにするかを計画しているよう
な人もいるでしょう。どちらかというと後者を想定してこの文書は構成してあ
ります。まずハードウェアの話から始め、設計に当たっての制約条件を述べ、
そして具体的な配置方法へと続きます。ここで紹介している手法は筆者自身も
用いており、自宅の PC と仕事で使っている多目的サーバの両方で非常にうま
く機能しています。またこの文書プロジェクトに参加している日本のユーザも
同様の手法を大学で利用しているサーバに用い、同様に成功しています。
この文書の最後には筆者自身が用いた設定チャートを紹介しています。こちら
に関するコメントや、また皆さんがご自分の設計作業から得た情報を、ぜひお
聞きしたいと思っています。そのような例が集まれば、この文書はさらに更新
できるでしょう。
2.3. リーダースガイド
まだ最大の HOWTO になったわけではありませんが、でもこの文書はだいぶ大
きくなりました。全体を読み通すのはしんどいので、どの部分を読めば良いか
を教えてほしい、というリクエストをいただきましたので、以下に挙げてみま
す。
エキスパート (エリート)
Linux やディスクドライブの技術について良くご存じなら、あなたが
もっとも望んでいる情報はきっと付録にあるでしょう。また FAQ と ``
補遺'' の章も読んでいただきたいと思います。
経験者 (有能な人)
コンピュータ一般に対する知識を持っている人は、 ``最新技術'' の章
に飛んで、以降を読み進めてください。
初心者 (タコ)
全部読む必要があると思います、ごめんなさい。また、他のディスク関
連の HOWTO も読むことをお勧めします。
3. ドライブの技術
IBM PC のドライブの技術に関しては、この文書よりもずっと充実した議論が
The Enhanced IDE/Fast-ATA FAQ の Web ページにあります。これは
Usenet ニュースにも定期的にポストされています。また ATA と ATAPI の情
報やソフトウェアを集めたサイト もあります。
ここではセットアップの際に必要となるドライブ関連技術の知識をかいつまん
で示します。
3.1. ドライブ
ドライブとはデータを保持する物理デバイスのことです。とてもたくさんの種
類があり、オペレーティングシステムからはどれも似たように見えますが、中
身は非常に異なっています。それぞれがどのように機能しているかを知ること
は、後で行なうディスク配置の際に大きな助けとなるでしょう。フロッピード
ライブに関しては今のところ無視していますが、もし要望が多ければ将来追加
するかもしれません。
3.2. ジオメトリ
ディスクドライブは 1〜数枚の円板 (platter, プラッタ) からなっており、
ここにデータが読み書きされます。読み書きを行なうのは移動式のヘッドに固
定されたセンサーです。すべてのヘッドはひとつのアームに固定されていて、
一緒に動きます。したがってデータ転送は全部の面から同時にされることにな
り、これがトラックの「シリンダ」となります。またドライブは「セクタ」に
よっても分割されています。セクタは多数のデータフィールドから構成されて
います。
これらシリンダ (Cylinder)、ヘッド (Head)、セクタ (Sector) の数 (以下
CHS と呼びます) のことをまとめて「ジオメトリ」と言います。ドライブはこ
のジオメトリによって分類されます。
色々な理由から、今では以下のようなものの間で CHS データの変換がされる
ようになっています。
o ドライブそのものの物理 CHS。
o ドライブが BIOS や OS に伝える論理 CHS
o OS によって用いられる論理 CHS
このようになってしまっているのは、つまるところシステムの出来が悪いため
で、様々な混乱の原因となっています。もっと知りたい方には Large Disk
HOWTO を推薦しておきます。
訳注: JF に Large Disk HOWTO の日本語訳
があります。
3.3. メディア
メディアの技術は、ディスクの読み書き速度・シーク時間・記憶容量・書き込
み可能かリードオンリーとなるかなどの重要な要素を決定づけます。
3.3.1. 磁気ディスク
読み書き可能な大容量記憶媒体として代表的なものです。コンピュータ分野の
通例にもれず、様々な特性、機能のものが乱立しています。読み書き可能な通
常のメディアの中では最速のものと言って良いでしょう。ディスクは一定の角
速度で回転しています。磁気媒体の面積を有効に利用できるように、物理セク
タの線密度はディスクの内側と外側で異なっています。長さ当たりのビット数
がだいたい一定になるように、外側のトラックでの論理セクタの数を増やして
あるのです。
回転角速度は通常 4500 か 5400 RPM (rounds per minute: 一分間あたりの回
転数) です。 7200 RPM のものも出まわっています。ごく最近では 10000 RPM
の製品も市場に出はじめているようです。シーク時間は 10 ms 程度です。転
送速度はモデルによってだいぶ違いがありますが、通常およそ 4〜40 MB/s 程
度です。高い性能を持ったドライブでは、電力が余計に必要になることも忘れ
ないでください。この電力は最終的には熱に転化します。この点については
``電力と発熱'' の節を参照してください。
データの転送にはいくつかの段階があり、それぞれ異なった単位が用いられる
ことに注意してください。まずプラッタからドライブ内のキャッシュまでの転
送があり、これは通常 Mbits/s で表されます。一般的には 50〜250 Mbits/s
程度のものが多いようです。次にドライブ内に組み込まれたキャッシュからホ
ストアダプタまでの転送があります。これは MB/s で記述され、 3〜40 MB/s
程度であることが多いようです。ただしこれはキャッシュの中にデータが存在
している場合の最高速度を表したものであり、実際の転送速度はもっとずっと
低くなります。
3.3.2. 光ディスク
光を利用した読み書き可能なディスクも存在していますが、遅いのでそれほど
一般的ではありません。 NeXT のマシンで用いられているようですが、遅いせ
いで良く文句のタネになっています。データの保存には相変化を用いますが、
このときの熱特性が書き込み速度を決めています。たとえ強力なレーザを用い
たとしても、相変化を引き起こす温度変化にかかる時間は磁気ドライブの磁気
効果の時間よりも遅いのです。
今日では多くの人々が CD-ROM を利用するようになっています。名前からわか
るように、これはリードオンリーです。容量はおよそ 650 MB、転送速度はド
ライブによりますが 1.5 MB/s 以上のものもあるようです。データは渦巻状の
一本のトラックに保存されます。したがってジオメトリは意味を持ちません。
データ密度はトラック上で一定で、ドライブは線速度が一定になるように回転
します。トラックが渦巻であるためにシーク動作も低速で、大体 100 ミリ秒
程度です。最近では線速度一定動作と角速度一定動作を組み合わせて性能を最
適化させるようにもなってきています。これによりシーク時の回転速度合わせ
の動作が軽減されるため、アクセス時間も短縮できます。
新型の光ディスク (DVD) も姿を現しつつあります。これは一枚のディスクに
18 GB の容量を記録できます。
3.3.3. 固体素子ディスク
比較的最近利用されるようになった技術で、ポータブルコンピュータや組み込
みシステムではポピュラーになってきています。動作部分が無いのでアクセス
も転送も非常に高速です。フラッシュ RAM が最も良く用いられていますが、
他の形式もあります。数年前には磁気バブルメモリが嘱望されたこともありま
したが、高価なので一般的にはなりませんでした。
ところで RAM ディスクを用いるのは一般に良くないとされています。 RAM
ディスクにするメモリがあるなら、その分を OS に管理させ、バッファや
キャッシュ、プログラム領域、データ領域などとして利用する方が有効だから
です。 RAM ディスクが有効なのは非常に特殊な場合、例えばタイムマージン
の厳しいリアルタイムシステムなどだけであると考えてください。
今日では数 10 MB サイズのフラッシュ RAM が利用できるようになりましたの
で、これを高速な一時記憶領域として利用したくなるかもしれません。しかし
これには大きな問題があります。フラッシュ RAM には寿命があって、再書き
込みを行える回数に制限があるのです。したがってこのようなデバイスをス
ワップや /tmp, /var/tmp などにあてがうと、これらの寿命を非常に縮めるこ
とになってしまいます。そのかわりに、フラッシュ RAM を「頻繁に読み込ま
れるがめったに書き込まれないディレクトリ」に用いると、非常に性能が向上
するでしょう。
フラッシュ RAM の寿命をより長くしたい場合は、専用のドライバを用いて
RAM の全領域を均等に用いたり、ブロック消去の回数を減らしたりする必要が
あるでしょう。
これは「ディレクトリごとに割り当てるデバイスを変える」ことによる利点を
示す例であると言えます。
固体素子のディスクは実体としての CHS アドレスを持っていません。しかし
OS とのインターフェースを共通にするために、ドライバが見せかけの CHS ア
ドレスを割り当てるようになっています。
3.4. インターフェース
世の中には選ぶのに困ってしまうほど多種多様のインターフェースがあり、価
格や性能も様々です。最近のほとんどのマザーボードには、新世代のチップ
セットの一部として IDE のインターフェースが付属しています。
SCSI インターフェース機能を持っているマザーボードも多くなりました。こ
れらは Symbios (以前の NCR) のチップを直接 PCI バスに接続しています。
お使いのマザーボードの機能と BIOS サポートを調べておくと良いでしょう。
3.4.1. MFM と RLL
むかしむかし、まだ 20 MB のハードディスクが羨望の目で眺められていた頃
には、これらは最先端の技術でした。今日の容量と比べると、恐竜が地上を徘
徊していた頃なんじゃないかと思うかもしれませんね。恐竜同様、これらの技
術もすでに滅んでしまいました。今日のものに比べると速度でも信頼性でも劣
るからです。 Linux は MFM や RLL をサポートしていますが、これらのイン
ターフェースにドライブを繋ぐのは全くお勧めできません。それでも強いて繋
ぐなら、同じく過去の遺物である DOS を入れて、緊急用のパーティションに
しておくのがせいぜいでしょう。
3.4.2. ESDI
ESDI は SMD に合わせて作られた技術でした。 SMD インターフェースは「巨
大な」コンピュータで広く使われたインターフェースですが、これを ST506
インターフェースで用いられていたケーブルセットに合わせるためのものが
ESDI だったのです。 SMD で使われていた 60 ピン + 26 ピンのコネクタをペ
アで用意するより、両者をまとめた ST506 のセットのほうが便利だったので
した。 ST506 は「間抜け」なインターフェースで、コントローラとホストコ
ンピュータにいろいろな作業をすべて任せていました (CHS の場所の計算、
ヘッド位置の追跡などなど)。 ST506 にはコントローラが必要で、これはリカ
バーされたデータからクロックを取り出したり、メディア上でのトラック構造
の物理的な位置を 1 ビットずつ制御したりするものでした。 MFM や RLL,
ERLL/ARLL モジュレーション機構などを含めることにすれば、 ST506 はおよ
そ 10 年ほどの寿命を保ちました。一方 ESDI はインテリジェントなインター
フェースで、 1 ドライブあたり 3〜4 つものマイクロプロセッサを使うのが
普通でした。トラックのフォーマット、データ転送、シーク動作などの高レベ
ルのコマンドが使えました。データストリームからのクロックリカバリや、ク
ロックラインのドライブと NRZ へのデータ表示もドライブ側でできました。
ただしエラー修正はコントローラの受け持ちでした。 ESDI では可変長ビット
密度での記録も可能でした、というか他にもいろいろなデータ変調技術が使え
ました。データはドライブでローカルに生成・分解できたからです。 ESDI の
技術は、その多くが後に IDE に取り込まれましたが、 SCSI がポピュラーに
なるにつれ、コンピュータでは利用されないようになっていきました。 ESDI
は 10 年の寿命を保ったと書きましたが、それは PC でのことではなく、サー
バなど「巨大な」システムでのことでした。
3.4.3. IDE と ATA
その後の技術の進歩によって、ドライブを制御する回路は ISA スロットから
ドライブ本体に置かれるようになり、 IDE (Integrated Drive Electronics)
が誕生しました。 IDE は単純かつ安価で、またそれなりの速度を持っていた
ため、多くの BIOS 設計者がこの技術を用いました。その結果 (コンピュータ
業界には良くあることですが) 面倒な問題が起こりました。ヘッド数が 16 ま
でという IDE の制限と、シリンダ数が 1024 までという BIOS の制限が重ね
合わさって、悪名高き 504 MB の制限が生れたのです。さらにコンピュータ業
界の伝統に倣い、この問題の解決にはその場しのぎのお粗末な方法が選択され
ました。その結果全く互換性のない数多くの変換方法、様々な仕様の BIOS が
乱立しました。この結果 Linux で BIOS からドライブ容量の情報を取得する
のが非常に面倒になりました。インストール文書を隅から隅まで丁寧に読み、
使っている BIOS の種類とバージョンを調べなければならなくなったのです。
しかし幸いなことに Linux では BIOS を経由せずに直接カーネルにドライブ
のパラメータ (よって容量も) を渡すこともできます。 LILO と Loadlin の
ドキュメントを良く調べてみてください。 IDE と ATA (AT Attachment) と
は同じものです。 IDE でのデータ転送は CPU 主導型の Programmed I/O
(PIO) です。より効率的な Direct Memory Access (DMA) 技術は使われてい
ません。転送速度の上限は 8.3 MB/s です。
3.4.4. EIDE, Fast-ATA, ATA-2
この 3 つは大体同じものです。 Fast-ATA と ATA-2 は同じもので、 EIDE は
これにさらに ATAPI を加えたものです。 ATA-2 は今日非常に広く用いられて
おり、 IDE より高速で DMA も使っています。転送速度は 16.6 MB/s に増加
しています。
3.4.5. Ultra-ATA
より高速な新しい DMA モードで、 EIDE PIO-Mode 4 のおよそ２倍の速度 (33
MB/s) です。 Ultra-ATA モードを持つディスクと持たないディスクは同じ
ケーブルで共存でき、それによって高速な方のドライブのスピードが低下する
こともありません。 Ultra-ATA インターフェースは電気的にはノーマルの
Fast-ATA インターフェースと等価で、ケーブルの最大長も同じです。
ATA/66 に続いては ATA/100 が登場し、ごく最近では ATA/133 も入手できる
ようになりました。インターフェースの速度は劇的に向上してきていますが、
ディスクのほうは大抵プラッタからキャッシュまでの転送速度で制限されてお
り、現在はだいたい 40MB/s です。
これらに関してもっと調べるには、 Maxtor から出されている概要とレポート
を調べましょう。 ATA/133 インターフェースについては Fast Drives
Technology に、
137 GB の制限を越える方法については Big Drives Technology
にあります。
3.4.6. Serial-ATA
Serial-ATA インターフェースという新しい標準が合意されました。 The
Serial ATA グループが支持しており、 2001
年 8 月にアナウンスがなされました。
たくさんの長所があります。以前の面倒な帯状ケーブルではなく細い接続で良
く、空気の流れも邪魔せずにすむ、高速 (約 150 MB/s)、過去互換性などで
す。
3.4.7. ATAPI
ATA パケットインターフェースは IDE のポートで CD-ROM ドライブを利用す
るために設計されました。 IDE と同様、ATAPI は安価でシンプルです。
3.4.8. SCSI
SCSI (Small Computer System Interface) は、ドライブだけでなくディス
クアレイやプリンタ、スキャナなど、色々なものを繋げる多目的インター
フェースです。 SCSI はマルチタスク環境に適しているため、ワークステー
ションなどのハイエンド機に用いられてきました (したがって "Small" とい
うのは正確ではないかもしれません)。
SCSI のバンド幅は標準で 8 ビットで、 8 つのデバイスを接続できます。
wide SCSI と呼ばれる規格ではバンド幅は 16 ビット (したがって転送クロッ
クが同じなら転送量は 2 倍)、接続可能なデバイスは 16 個となっています。
ホストアダプタもひとつのデバイスとみなされます。普通は 7 番がホストア
ダプタの ID に割り当てられます。 32 ビットの wide バスを使うこともでき
ますが、この場合すべての信号線を接続するには、通常ケーブルが 2 セット
必要になります。
古い標準の規格では転送速度は 5 MB/s でしたが、新しい fast-SCSI では 10
MB/s に増えています。最近では ultra-SCSI (Fast-20 とも呼ばれます) と
いう規格が定まり、 8 ビット幅のバスで 20 MB/s の転送量を持つようになり
ました。最新の、低電圧差動信号 (Low Voltage Differntial signal: LVD
signal) を用いる方式では、同程度の高い速度に加え、以前よりずっと長い
ケーブルを使うことができます。
さらに最近には、もっと速い規格も導入されています。 SCSI 160 (もとの名
前は SCSI 160/m) で、 16 ビット幅のバスを用い、なんと 160 MB/s の能力
を持っています。実装はまだまだですが、 10000 RPMディスクの中には 40
MB/s の転送を定常的に行えるものもあります。このようなディスクを 6 台集
めて RAID にすれば、こんなバスも飽和させてしまうことができます (PCI バ
スも同様)。現段階では、明らかに最高級のハイエンドサーバ用のものです。
この規格に関するより詳しい情報は The Ultra 160 SCSI home page
から入手できます。
最近 Adaptec は、彼らの 160 ホストアダプタ用の Linux ドライバの発表を
しました。詳しいことがわかりしだい、ここでもお知らせします。
現在では SCSI/320 も出ています。
通常 SCSI は (E)IDE よりも高性能ですが、価格も高い場合が多いようです。
ドライブも SCSI の方が IDE より性能が高い場合が多いです。一方デバイス
を追加するのは SCSI の方が簡単で、ほとんどの場合は単にデバイスを抜き差
しするだけです (中には電源を入れたままでこれをやる人もいます)。これは
複数のシステムを持っている場合には非常に便利で、どれかのシステムが何ら
かの理由で故障しても、デバイスを移すだけですみます。
SCSI に関してはためになる文書がたくさん出ています。 SCSI HOWTO や SCSI
FAQ などは、 Usenet ニュースにもポストされています。
SCSI にはバックアップのためのテープドライブや、一部のプリンタやスキャ
ナを接続できるという利点もあります。また別々のコンピュータを一つの
SCSI バスに繋ぎ、デバイスを共有させることで、超高速のネットワークを作
ることさえ可能です。作業は進行中のようですが、接続された別々のコン
ピュータの間でキャッシュの整合性を保証するのが難しく、それほど簡単な仕
事ではないようです。
SCSI 番号は調停 (arbitration) にも使われます。複数のドライブが要求を同
時に出した場合、もっとも低い番号のドライブが優先されます。
新しい SCSI カードには、タイプの異なる複数の SCSI デバイスを、それぞれ
最適な速度で同時に使えるようなものもあります。
3.5. 配線
ハードウェア寄りの話をするつもりはあまりなかったのですが、配線に関して
は少々触れておく必要があるように感じました。特に技術的に難しい部分では
ないのですが、ここがいろいろな問題の原因になっていることが多いのです。
今日のように高速な転送が行われるようになると、ケーブルは高周波デバイス
として考える必要があり、インピーダンスマッチングが重要になります。しか
るべき措置を行っておかないと信頼性は非常に低下しますし、まったく動かな
くなることもありえます。 SCSI ホストアダプタの一部の製品は、この点に非
常に敏感です。
シールドケーブルはシールドされていないケーブルより良いに決まっています
が、価格もとても高価になります。少々注意を払えば、安価なシールドのない
ケーブルでも充分な性能が得られます。
o Fast-ATA と Ultra-ATA では、ケーブルの最大長は 45 cm (18インチ) と
決められています。二つの IDE チャンネルのデータ線が結線されているよ
うなマザーボードも多く、これらでは 2 つのチャンネルが 一本の ケーブ
ルとして扱われます。いずれにしても、 EIDE のケーブルはできる限り短
くすべきです。原因不明のクラッシュや間欠的なデータ破壊などが生じた
場合には、ケーブルを調べて見る価値はあるでしょう。より低速な PIO
モードを試したり、二番目のチャンネルを外してみて問題が解決するかど
うか見てみてください。
o ATA ドライブで Cable Select をさせるには、ドライブのジャンパを
cable select にして、マスターかスレーブかはケーブルに決めさせます。
これはあまり用いられていません。
o プライマリにしろセカンダリにしろ、 ATA コントローラにマスターをつな
がずスレーブだけを接続してはいけません。このような場合、動作がどう
なるかはわかりません。
o ケーブルはできるだけ短くしましょう。しかし ultra SCSI の場合には最
低 30 cm の間隔が、ディファレンシャル SCSI の場合は 60 cm の間隔が
必要なことも忘れないように。
o ケーブルとデバイスの間に長いスタブ (stub) を用いるのは止め、ケーブ
ルのプラグはドライブに直に接続するようにしましょう。
o SCSI の配線に置ける制限一覧:
Bus Speed (MHz) | Max Length (m)
--------------------------------------------------
5 | 6
10 (fast) | 3
20 (fast-20 / ultra) | 3 (max 4 devices), 1.5 (max 8 devices)
xx (differential) | 25 (max 16 devices
--------------------------------------------------
o SCSI デバイスのターミネーションは正しい位置のものを有効にしましょ
う。 SCSI チェーンの両端です。ホストアダプタにもオンボードのターミ
ネーションがついているかもしれません。
o シールドケーブルとシールド無しのケーブルを混ぜて使わない、ケーブル
を金属の周りに巻かない、金属部分を配線から遠ざけるようにする、など
の注意をしてください。配線に不連続な部分があると、そこでインピーダ
ンスのミスマッチが生じ、信号の反射が起こってケーブルのノイズとなっ
てしまいます。この問題はマルチチャンネルのコントローラではよりシビ
アになります。最近、発泡プラスチックでケーブルの周りを覆い、ケーブ
ルが金属部分に近づきすぎないようにすると良い、と教えてくれた人がい
ました。でも本当の問題は、ケースの中が混んでいることにあるのですよ
ね。
SCSI の配線や終端処理に関するより詳しい情報はネットのたくさんの web
ページに書かれています。
3.6. ホストアダプタ
ドライブからのインターフェースケーブルを繋ぎ、コンピュータのバスとの仲
立ちをします。コンピュータバスの速度とドライブの速度は同程度のものを利
用すべきで、そうでないとどちらかがボトルネックになります。例えば RAID
0 のディスクセットを ISA のバスに繋いだりするとそういうことになりま
す。最近のコンピュータのほとんどでは 32 ビットの PCI バスを使うことが
できます。これは 132 MB/s の転送速度を持っていますので、しばらくの間は
ボトルネックになることなく利用できるでしょう。
ドライブの制御回路の大部分がドライブ本体に収められるようになると、残り
の部分である (E)IDE インターフェースは非常にコンパクトになり、 PCI の
チップセットに標準的に用意されるようになりました。 SCSI ホストアダプタ
はもう少し複雑で、専用の CPU を使ったりすることも多いため、 IDE に比べ
て高価です。まだ PCI チップセットにも取り込まれていないようです。もち
ろん技術が進歩すれば状況は変わるでしょう。
ホストアダプタには独自のキャッシュや拡張制御機能を持っているものもあり
ます。しかしこれは本来 OS の機能のはずなので、使っている OS によって効
果があったりなかったりします。原始的な OS (特に名を秘す :-) では高い効
果が得られることもありますが、 Linux はもともと良くできているので、こ
れらの機能によって得られる効果はたいした物ではありません。
DPT コントローラのドライバを書いた Mike Neuffer によれば、 DPT のコン
トローラはとても賢く、充分なキャッシュメモリをあてがってやれば非常に性
能が向上するそうです。またこの事から彼は、インテリジェントな SCSI コン
トローラで性能が向上しないのは、キャッシュコントローラの方の問題ではな
いかと言っています。
3.7. マルチチャンネルシステム
スループットを上げるには、最大のボトルネックを特定し、それを排除する必
要があります。システムによっては (特にたくさんのドライブを接続している
システムでは) 複数のコントローラを並列動作させることで効果が得られるこ
とがあります。これは SCSI でも IDE でも同じです (IDE はもともと 2 チャ
ンネル付いているハードウェアが多いでしょう)。 Linux でもこのような動作
はサポートされています。
RAID コントローラの中には、二つまたは三つのチャンネルが付いていて、
ディスクアクセスを別々のチャンネルに振り分けることができるようなものも
存在しています。別の言い方をすれば、 2 チャンネルのコントローラに対し
て RAID にしたい 2 台の SCSI ドライブがある場合には、それらは別々の
チャンネルに接続すべきだ、ということです。
3.8. マルチボードシステム
一台のマシンには SCSI と IDE の両方を繋ぐことができますが、さらに 2 つ
以上の SCSI コントローラを接続することもできます。可能なコントローラの
組合せは SCSI-HOWTO をチェックしてください。さらに、複数の SCSI, IDE
コントローラをプローブするようにカーネルに教えてやる必要があるでしょ
う。これはブート時にカーネルにパラメータを与えることによって実現しま
す。例えば LILO などが使えます。これには SCSI や LILO の HOWTO を
チェックしてください。
マルチボードのシステムでは、ディスクの配置を正しく設定すれば、大きな速
度性能の向上が期待できます (とくに RAID 0 では)。コントローラーやドラ
イブを互い違いにして、 md の RAID デバイスに正しい順序でドライブを追加
してください。コントローラ 1 にドライブ sda と sdc が、コントローラ 2
にドライブ sdb と sdd が接続されていたとしますと、並列性を最大にするに
は sda - sdc - sdb - sdd の順序で繋ぐことです。なぜなら互い違いに接続
すると、 2 クラスタ以上の読み書きが二つのコントローラにまたがるように
なるからです。 sda - sdb - sdc - sdd ではあまり効果が上がりません。
同じ手法は IDE にも使えます。ほとんどのマザーボードでは、 4 つの IDE
ポートが使えます。
o hda プライマリ マスター
o hdb プライマリ スレーブ
o hdc セカンダリ マスター
o hdd セカンダリ スレーブ
ここでプライマリの 2 台、セカンダリの 2 台はそれぞれフラットケーブ
ルを共有します。先進的なチップセットでは、この二組はそれぞれ独立し
ています。したがって RAID を構成するときの最適な順序は hda - hdc -
hdb - hdd で、このとき両チャンネルの並列性がもっとも期待できること
になります。
3.9. 速度比較
以下の表は転送速度をまとめたものです。ただしこれらは理論上の最大値に過
ぎないことに注意してください。転送速度の単位は MB/s です。バスの幅の単
位はビットです。
3.9.1. コントローラ
IDE : 8.3 - 16.7
Ultra-ATA : 33 - 66
SCSI :
Bus width (bits)
Bus Speed (MHz) | 8 16 32
--------------------------------------------------
5 | 5 10 20
10 (fast) | 10 20 40
20 (fast-20 / ultra) | 20 40 80
40 (fast-40 / ultra-2) | 40 80 --
--------------------------------------------------
3.9.2. バスの形式
ISA : 8-12
EISA : 33
VESA : 40 (Sometimes tuned to 50)
PCI
Bus width (bits)
Bus Speed (MHz) | 32 64
--------------------------------------------------
33 | 132 264
66 | 264 528
--------------------------------------------------
3.10. ベンチマーク
これはとても、とっても難しい問題です。ここではこの地雷原に対する警告を
いくつか挙げるにとどめておきます。まず、実際に何らかの意味を持つベンチ
マークを行い、この結果から有益な結論を導き出すのは、とても難しいことな
んです。とはいっても、これくらいでやめるような人はいませんよね...
どちらかというと、自分自身のシステムが以前と同じくらい速いままであるか
(つまり、遅くなっていないか) を診断するためにベンチマークを使うのがい
いでしょう。また例えば、単純なファイルシステムから RAID に変更した場合
はかなりの効果が見込めるはずですから、性能に変化がなければどこかがおか
しい、などのチェックにも使えるでしょう。
ベンチマークを行うときには、自分独自の方法は使わず、 iozone や bonnie
を使うようにし、文書を隅々まで読むようにしてください。特にバッファのサ
イズは必ず RAM のサイズより大きくしてください。さもないとディスクでは
なく RAM のテストをすることになってしまい、非現実的に高い性能が得られ
てしまいます。
非常に簡単ではありますが、 hdparm -tT でもベンチマークを行うことができ
ます。これは IDE のドライブでも SCSI でも使えます。
ベンチマークや各種プラットフォームにおけるソフトウェアに関するより多く
の情報は ACNC のベンチマークペー
ジを見てください。こちらのページ や The
Benchmarking-HOWTO . などもどうぞ。
現在では bonnie , bonnie++
, iozone に
は、それぞれ公式ページもあります。
雑学: Bonnie はローカルなボトルネックの発見用のもので、名前は Bonnie
Raitt, 「ボトルネックの使い方を知ってるひと」にちなんでつけた、と著者
は書いています。 (訳注: Bonnie Raitt はギタリストです :-)
3.11. 比較検討
SCSI の性能は EIDE より高いですが、値段も高くなります。 SCSI ではケー
ブル終端の処理が面倒ですが、拡張は楽です。 4 台 (場合によっては 2 台)
以上の IDE ドライブを使うのは大変ですが、 wide SCSI なら 15 台まで簡単
に使えます。複数のチャンネルを持っている SCSI ホストアダプタなら、この
台数はチャンネル数を乗じたものになり、さらに多くなります。
SCSI では、ホストアダプタ一つにつき一つの IRQ が必要で、これで 15 台の
ドライブをまかなえます。これに対して EIDE では IRQ がチャンネル一つ (
ディスク二台までつなげます) に一つ必要で、これは conflict の原因になる
かもしれません。
RLL と MFM は一般的に言って古すぎます。たいていの用途には速度、信頼性
とも足りないでしょう。
3.12. 将来の開発予定
SCSI-3 も策定中で、リリースは近そうです。より高速のデバイスに関しては
すでにアナウンスがあり、ごく最近には 80 MB/s、さらには 160 MB/s という
モンスター規格も提案され、ごく最近には商品も出ました。これらは 40 MHz
のクロックを用いる Ultar-2 規格で、 16 ビットのケーブルを用いるもので
す。
SCSI-3 対応デバイスをアナウンスしたメーカーもあるようですが、標準規格
がまだしっかり定まっていない現在では、これはまだ時期尚早といったもので
しょう。転送速度が上昇するにつれ、 PCI バスのバンド幅がいっぱいになる
日も近いかもしれません。現在の 64 ビットバージョンの PCI バスのリミッ
トは 264 MB/s となっています。将来 PCI のクロックは現在の 33 MHz から
66 MHz へ上がるようで、そうするとリミットは 528 MB/s となります。
ATA の開発は続いており、新たな ATA/100 標準の登場に伴って性能も向上を
続けています。ほとんどの ATA デバイスでは、プラッタからの定常的な転送
速度はこれより遅いので、ほとんどの人にとっては性能向上はあまり大きくな
りません。
より興味深いのはシリアル ATA の開発です。これはフラットケーブルの代わ
りに高速なシリアル接続を用います。配線は現在のものよりずっと単純にな
り、ケーブリングによってドライブ周りの空気の流れが阻害される問題も解決
できます。
もうひとつの流れはディスクの巨大化です。最近聞いた話では、一台のドライ
ブで 75 GB を実現することも可能だそうです (高価になるでしょうが)。現在
のところではコストパフォーマンスが最も良いのは 30 GB のクラスでしょう
が、このサイズも大きくなり続けています。近い将来に DVD が出てくれば、
大きなインパクトが期待できます。 DVD は一枚のディスクに 18 GB を記録で
きます。これは世界各地にある有名な FTP サイトをフルコピーできる容量で
す。ディスク技術の「質」が上がるかどうかは確言できませんが、「量」は確
実に増えていくでしょう。
追加：この部分を書いてからすぐ、 CD-ROM の最大速度が 20 倍速となり、機
械的な安定性が大きな問題になるであろうという記事を目にしました。またそ
の一ヶ月後、今度は 24 倍速の CD-ROM の宣伝が出ていました... (訳注: も
う今では 24 倍も普通になってますね) おそらく 40x 以上のものが、すでに
出荷直前の段階にあることでしょう。
SCSI を TCP/IP にカプセル化する、 iSCSI という名前のプロジェクトがスタート
しており、 Linux iSCSI implementation
も登場しています。
3.13. お薦め
筆者の個人的な意見では、システムを初めて作る場合には EIDE または
Ultra-ATA が最適です。特に DOS を同時に使う場合はこれで充分です。一方
システムを何年にもわたって拡張する予定や、サーバとして使う予定があるの
でしたら、 SCSI のドライブを強くお薦めします。現在のところ wide SCSI
はまだ少々高価なようですので、 8 ビット幅の SCSI を選ぶ方がコストパ
フォーマンスが良いでしょう。ケーブルの最大長を大きく取れるような SCSI
バスの規格もあるようですが、値段はさらに割高になるので普通のユーザには
お薦めしません。
SCSI バスにはディスクドライブだけではなく、製品を限ればスキャナやプリ
ンタ、ネットワークなどを繋ぐこともできます。
システムの拡張にあたっては、より大きな電力が必要になることも忘れないで
ください。使っている電源の容量が足りるか、冷却が充分かどうかにも気をつ
けなければなりません。 SCSI ドライブの多くはスピンアップを順番に行う機
能を持っているので、大きなシステムにはこれを用いるのが良いでしょう。
``電力と発熱'' の節にある情報も参考にしてください。
4. ファイルシステムの構造
Linux は開発のごく初期からマルチタスクで、そこではたくさんのプログラム
が相互作用しながら共存しています。したがってファイル構造を皆が納得でき
るように保ち、システムが必要なデータをそれと分かる場所に配置することが
大切です。歴史的には、異なった標準がたくさん存在していたため、混乱の原
因となっていました。またそれらの互換性を取るためにシンボリックリンクが
多用され、さらに混乱を引き起こしてファイル構造をまるで迷路のようにして
しまったのです。
幸いなことに Linux の場合には、早いうちに File Systems Standard
(FSSTND) という規格が合意され、今日の Linux ディストリビューションのほ
とんどで用いられるようになりました。
その後この後継規格として、 Linux 以外の OS でも用いることのできるよう
なものを策定することになりました。これは Filesystem Hierarchy Standard
(FHS) と呼ばれ、現在は version 2.2 です。この規格はまだ開発もされ続け
ていますが、近いうちに各ディストリビューションに採用されることでしょ
う。
自前の構造を作ろうとはしないほうがいいでしょう。 FHS には多くの考えが
盛り込まれており、またソフトウェアパッケージの多くがこの規格に準拠して
きているからです。そんな余裕があったら、 FHS home page
から、FHS に関する情報をもっと読んでみ
ましょう。
この HOWTO は FSSTND に準拠しようと努力しています。 FHS 向けのディスト
リビューションが出てきたら、 FHS に準拠したものにする予定です。
4.1. ファイルシステムの特徴
FSSTND 中の様々な構成要素に対しては、それぞれ異なった速度・信頼性・容
量が必要になります。例えばルートパーティションを失っても、痛手ではあり
ますが修復は比較的簡単です。一方 /var/spool/mail を失うのは非常にまず
いでしょう。ここではいくつかの主要なディレクトリについて、それぞれの特
徴と要求される性能とを簡単にまとめてあります。この部分は一般的な話であ
ることを承知しておいてください。実行バイナリが etc や lib ディレクトリ
に置かれたり、ライブラリファイルが bin ディレクトリに置かれたりするこ
となども実際にはあります。
4.1.1. スワップ領域
速度
最速のものを。しかしスワップに頼りすぎているような場合は RAM を
買い足すことを考えた方が良いでしょう。ただし古い Pentium PC マ
ザーボードの多くでは、 128 MB 以上の RAM にはキャッシュが効かな
いかも知れないことに注意してください。
容量
考え方は RAM の場合と同じです。簡単な計算法をお教えしましょう。
紅茶の入れ方と一緒です。マシンに 16 MB、各ユーザに 2 MB ずつ。最
小のカーネルは 1 MB でもギリギリ走ります。普通の仕事や軽めのアプ
リケーションには 4 MB、X11 や gcc には 8 MB 用意しましょう。 16
MB あれば快適でしょう。 (著者は濃い目の紅茶を淹れることで知られ
ています...)
スワップとして RAM の 1〜2 倍を勧める人もいます。またどんなプロ
グラムが動いているかによってスワップスペースの有効性が決まるとい
う指摘もあります。 4BSD の場合に使われる見積もり方法は Linux の
場合にはあまり適当ではありません。 Linux は core の中にページン
グのための領域を確保しないからです。
もっと完全なやり方は、スワップスペースと RAM の和をあなたの用い
るワーキングセットの総計と考えることです。自分が必要とするメモリ
空間の最大量を知っているなら、そこから物理 RAM の量をひいてス
ワップの量とすれば良いわけです。
スワップのサイズを決めるときには、気前良くたくさん割り当てた方が
良いかもしれません。これには理由があります。メモリリークです。お
作法を守らないプログラムでは、自分に割り当てたメモリを解放しない
ものがあります。これを「メモリリークがある」と表現します。このよ
うなプログラムに割り当てられたメモリは、この悪党プログラムが終了
したあとでも解放されず、したがってメモリ消費の原因になります。プ
ログラムが死なない限り、メモリは返却されないのです。物理 RAM と
スワップスペースがすべて使われてしまったら、解決法はただ一つ、そ
のプロセスを殺すだけです。これに失敗したら、再起動しなおすしかあ
りません。ありがたいことにこのようなプログラムはそう多くはありま
せんが、でもいつかそんなプログラムに出くわしたときには、余分に
とっておいたスワップスペースのおかげで再起動の間の時間が長く取れ
るようになっていることがわかるでしょう。
使っているプログラムによっても話は変わってきます。画像処理ソフト
のように大きな実行領域を必要とするプログラムでは、 RAM に巨大な
データ構造がロードされ、ディスク上でデータが扱われることはあまり
ありません。このようなデータ負荷および CPU 負荷が高いプログラム
では、必要な RAM が無いとスワップの嵐に見舞われることになりま
す。
また、自分自身の実行イメージ (の一部) を RAM にロックしてしまう
プログラムもあります (ページロックと呼ばれます)。セキュリティの
問題からデータをスワップデバイスへコピーできないようなプログラム
や、あるいは高速処理が必要なリアルタイム指向のプログラムなどが該
当します。ページロックが行われるとスワップ可能なメモリ量が減りま
すから、予想より早い段階でスワップが起こることになります。
man 8 mkswap によれば、スワップパーティションひとつあたりについ
て、 32 ビットマシンなら 128 MB にちょっと足りないくらい、また
64 ビットマシンなら 256 MB にちょっと足りないくらいの大きさを割
り当てることができます。
しかしカーネル 2.2.0 以降では、この制限は 2 GB に変更されまし
た。 man ページもこの変更を受けて更新されました。
信頼性
中程度。障害が起こったときにはすぐわかりますし、それによって失う
ものもたいしたことはないでしょう。セーブはこまめにしてるでしょ？
注意 1
Linux では複数のデバイスにまたがるかたちでスワップを配置できま
す。この機能は使ってみると意外と便利です。詳しい内容については
"man 8 swapon" を見てください。ただしソフトウェア版 RAID を複数
のデバイスに用いて、それをスワップにするのはオーバーヘッドのほう
が大きいでしょう。
この場合の /etc/fstab/ ファイルの内容は以下のようになるでしょ
う。
/dev/sda1 swap swap pri=1 0 0
/dev/sdc1 swap swap pri=1 0 0
fstab は書式に非常に厳しいので、必ず man ページをしっかり読むように
してください。上の行をカット & ペーストするだけじゃ駄目ですからね。
注意 2
RAM ディスクをスワップなどのファイルシステムに使っている人がいる
ようです。しかし非常に特殊な場合を除けば、この方法はあまり得には
ならないでしょう。キャッシュやバッファに使えるメモリが減少してし
まうからです。
注意 2b
ひとつだけ例外があります。世の中には設計の悪いマザーボードがたく
さんあって、アドレスできる RAM のすべてをキャッシュできない場合
があります。古いマザーボードの多くでは、メモリは 128 MB 使えても
キャッシュはその内の 64 MB にしか効かないのです。このような場合
には、上位の (キャッシュされない) 64 MB の RAM をラムディスクに
して、スワップ領域や一時記憶領域にした方が良い場合があります。
4.1.2. 一時記憶領域 ( /tmp と /var/tmp )
速度
高速のものを。別のディスクやパーティションにおけば、フラグメン
テーションを減らせます。もっとも ext2fs はフラグメンテーションを
うまく扱うことができますので、それほど気にしなくても良いかもしれ
ません。
容量
難しいです。小さなシステムなら数 MB でも足りるでしょう。しかしこ
れらのディレクトリは、他のユーザや quota の制限からファイルを隠
すことのできる場所として知られているので、マルチユーザの大きなマ
シンでは際限無く大きくなることがあります。以下は筆者のお勧めで
す: 家で使う場合は、小さなマシンなら 8 MB、大きめの場合 32 MB。
小さなサーバでは 128 MB、大きなサーバで最大 500 MB。なお筆者が仕
事で使っているマシンでは 1100 名のユーザに対し /tmp ディレクトリ
を 300 MB とっています。これらのディレクトリには目を配っておき、
隠し属性のファイルや古いファイルに注意しましょう。パーティション
の切り直しが必要になるのは、ここのディレクトリが原因であることが
多いようです。
信頼性
低くて良いです。これらの領域が壊れていたり一杯だったりしても、大
抵のプログラムは礼儀正しくできていますので、警告を発するか停止し
てくれるでしょう。もちろんランダムファイルエラーはもっと深刻です
が、これはどんなファイル領域でも同じことです。
ファイル
ほとんどは小さなファイルですが、膨大な数になります。普通のプログ
ラムは使用した一時ファイルを消しますが、割り込みがあったりすると
残ってしまうこともあります。多くの配布パッケージでは tmp ファイ
ルを起動時に消去するような設定がなされています。自分のシステムで
はどうなっているか確認しておくと良いでしょう。
注意 1
FSSTND では /tmp を RAM ディスクに置くと良いといった記述がありま
す。しかしスワップのところで述べたのと同じ理由で、これはおすすめ
できません。また、これも先に述べましたが、フラッシュ RAM のドラ
イブをこれらのディレクトリに割り当てるのもやめましょう。
注意 2
古いシステムでは /usr/tmp があるかもしれませんが、これはもう推奨
されていません。ただし歴史的な理由から、他の tmp 領域へのシンボ
リックリンクとして残されていることがあるようです。
(* これで何行かな？いま自宅ですが、ノド乾いたなあ。*)
4.1.3. スプール領域 ( /var/spool/news と /var/spool/mail )
速度
特にニュースサーバ用途には速いものを。ニュースの配信や消去はディ
スクを酷使しますので、速いディスクから得られるメリットは大きいで
しょう。プリントスプールは遅くても良いです。ニュースには RAID 0
の使用も考えましょう。
容量
ニュース／メールサーバの場合はできる限り大きなものを。シングル
ユーザのシステムで常時読んでいるような場合は数 MB で十分でしょ
う。ただしトラフィックの大きいメーリングリストに参加している人が
休暇を取るような場合には、これでは足りないかも知れません。筆者が
仕事で使っているマシンでは /var/spool 全体に 100 MB を割り当てて
います。
信頼性
メールの場合は非常に高い必要があります。ニュースは普通、プリント
スプールは低くて良いでしょう。メールが重要なら (普通はそうで
しょ？) 信頼性を高めるために RAID の導入を考えましょう。
サイズ数 KB の大きさのファイルが非常にたくさん置かれます。逆にプ
リントスプールの場合は、数は少ないですが各ファイルはかなり大きな
ものになります。
注意
ニュース関連の文書では、 .overview ファイルをすべてまとめて、
ニュースファイルとは別のドライブに置くことを勧めているようです。
より詳しくは news に関する FAQ をチェックしてください。この大き
さはニューススプールの総量の 3〜10 パーセントくらいになります。
4.1.4. ホームディレクトリ ( /home )
速度
普通です。大抵のプログラムは一時的な保存場所に /tmp を用います
が、ニュースリーダのようにホームディレクトリのファイルを頻繁に更
新するプログラムもあります。小さなシステムでは問題にならないで
しょうが、大きなマルチユーザシステムだと気になることがあるかもし
れません。
容量
難しいです。ユーザがディスク容量に対して対価を支払うようなシステ
ムでは、これはお金の問題になるでしょう。 Nyx.net
はメール、ニュース、WWW といったインター
ネットサービスを無料で提供している大きなシステムですが、ユーザ一
人あたり最大 300 KB、推奨 100 KB という制限でうまく稼動していま
す。商用プロバイダの通常の契約では 5 MB 程度を利用できる場合が多
いようです。
本を書いたりデザインワークをしているような場合には、必要な容量は
フーセンのようにあっという間に膨らむでしょう。
信頼性
流動的です。シングルユーザのマシンで /home が失われるのも困った
ことではありますが、 2000 人のユーザから「ホームディレクトリが無
くなった」という電話を受けるのとは「困った」の度合が全然異なるで
しょう。彼らユーザの中には生活の糧となる情報をここに置いている人
もいるかもしれません。もちろん定期的なバックアップはしてますよ
ね？
ファイル
同じく流動的です。あるユーザ一人が最小のセットアップを行なった場
合は、ファイルが数 10 個、サイズは 0.5〜5 KB 程度になるでしょ
う。プロジェクト関連のファイルはずっとずっと大きくなるでしょう。
注意 1
スピードと信頼性を求めるなら RAID を考慮すべきです。さらなる高速
性や信頼性が必要なら、他の OS やプラットホーム (耐故障システムな
ど) を考えるべきでしょう。
注意 2
多くの Web ブラウザはブラウジングを高速化するためにローカルな
キャッシュを利用します。このキャッシュはかなりたくさんの容量を必
要としますし、またディスクに対するアクセス要求が頻繁になります。
これによって生じる性能低下を避ける方法はいくつかあります。具体的
な情報に関しては ``ホームディレクトリ'' や ``WWW'' の節を参考に
してください。
注意 3
ユーザーは /home に割り当てられた自分のスペースを簡単に使い切っ
てしまうものです。 Linux の Quota サブシステムはユーザー ID ひと
つあたりに割り当てるブロック数と inode 数をファイルシステム単位
で制限できます。設定の詳細は Albert M.C. Tam bertie (at) scn.org
の書いた Linux Quota mini-HOWTO
を見てください。
訳注: Quota mini-HOWTO の日本語訳
は JF にあります。
また最新の quota システムのマニュアルの翻訳が JM Project
でなされています。
4.1.5. バイナリ ( /usr/bin と /usr/local/bin )
速度
遅くて良いです。プログラムはデマンドロードされるので、むしろデー
タの方が大きいことの方が多いです。したがって速度は重要ではありま
せん。 CD-ROM 上の live ファイルシステムの成功が証拠です。
訳注: live ファイルシステムとは CD-ROM 上にルートファイルシステ
ムを置いて直接ブート可能にしたものです。詳細については
などをご覧ください。
容量
上限は遥か天空の彼方ですが、大抵のシステムなら 200 MB あれば必要
なものの大部分は入るでしょう。ソフト開発を行うホストや多目的サー
バなどの大きなシステムではインストール時に 500 MB、 将来のために
さらに 500 MB の領域を確保しておくと良いでしょう。
信頼性
低くて良いでしょう。このパーティションは普通ルートパーティション
にマウントされるでしょうが、ほんとうに大事なものはルートに入って
いるでしょうから。しかしバイナリをすべて失うのは痛いことは痛いで
すね...
ファイル
いろいろな大きさのファイルがあるでしょうが、だいたい 10〜100 KB
くらいのものが多いでしょう。
4.1.6. ライブラリ ( /usr/lib と /usr/local/lib )
速度
普通です。ここにはオブジェクトファイルからフォントに至るまで、頻
繁にロードされる図体のでかい (しかも近年さらに拡大傾向にある)
データが置かれます。これらは一度に全体がロードされるので、ここに
速いディスクを使うのはそれなりの価値があります。
容量
流動的です。例えばワードプロセッサなどが大量のフォントファイルを
保存するような場合もあります。この文書に対してフィードバックをく
れた方の中には、種々の lib ディレクトリに 70 MB 使っている人もい
ました。 Debian 1.2 をほぼすべてインストールすると、だいたい 250
MB になります。これを実際の上限と考えておくと良いでしょう。ディ
スク食いの最たるものとしては、 GCC, Emacs, TeX/LaTeX, X11, perl
などがあります。
信頼性
低くて良いです。理由は ``バイナリ'' の節で述べたものと同じです。
ファイル
普通は大きく、 1 MB のオーダーのものが多いでしょう。
注意
歴史的な理由から、いくつかの実行プログラムファイルは lib 領域に
置かれています。例えば GCC はいくつかの非常に大きなバイナリファ
イルを /usr/lib/gcc/lib 以下のディレクトリに置いています。
4.1.7. Boot
速度
非常に遅くてかまいません。ブートはそんなに頻繁に行われるものでは
ないですし、カーネルのロードもシステムの立ち上げにかかる時間のほ
んの一部でしかありません。
容量
極めて小さくて良いでしょう。完全なイメージにいくらか追加をしても
1 枚のフロッピーに収まるのですから、 5 MB あれば十分過ぎるでしょ
う。
信頼性
高い必要があります。以下の Root の部分を参照。
注意 1
Boot パーティションについて最も気をつけなければいけないことは、
これは多くのシステムでは 1023 シリンダ以下の部分に置かなければな
らない、ということです。これは Linux では回避できない BIOS の制
限なのです。
注意 1a
上記は最近の IDE システムには必ずしも当てはまりません。また SCSI
ディスクにも当てはまりません。より詳しい情報は最新の Large Disk
HOWTO を参照してください。
注意 2
1023 セクタの制限を受けない新しいブートローダが、最近開発されま
した。詳細は nuni に関する記事
を見てくださ
い。
4.1.8. ルートファイルシステム
速度
かなり遅くても大丈夫です。ほんとうに必要最小限のものしかここには
ありませんし、大部分は起動時にしか実行されません。
容量
比較的小さくて良いでしょう。しかしシステム修復に必要なファイルや
ユーティリティ、バージョンの違ういくつかのカーネルなどをルート
パーティションに置いておくのも良いアイデアだと思います。この文書
に対するフィードバックをまとめると、 20 MB あれば十分なようで
す。
信頼性
高くなければなりません。このブートパーティションが壊れると、悲し
い思いをする人が多いでしょう。また復旧にも結構な時間がかかってし
まいます。もちろん練習を積めば 1 時間かそこらで復旧できるように
もなるでしょうが、復旧の練習を積んでいる人は何か別のヘマもしてい
る人だと筆者は思います。
もちろんレスキューディスクは用意してありますよね。最初のインス
トールのときからアップデートしましたか？世の中には有用なレス
キューディスクや、ディスク作成用のツールが多く存在します。ルート
システムのレスキューの専門家になるよりも、これらのツールを探す方
が時間を有効に使えるでしょう。
注意 1
ドライブがたくさんあるのでしたら、緊急用としてスペアのブートパー
ティションを別のドライブに用意しておいても良いかもしれません。
ディスク容量は少々損しますが、セットアップにかかる時間を考えれ
ば、何かが壊れたときの保険としては充分価値があります。
注意 2
ルートパーティションを RAID 0 のシステム上に置くのはお勧めできま
せん。立ち上げ動作が複雑になりますし、障害の際にも問題がありま
す。また、ブートパーティションに RAID を使う場合は、レスキュー用
カーネルの md 機能を忘れずに有効にしておくことです。
注意 3
システムを単純化するため、 Boot と Root を同じパーティションに配
置することはごくごく普通に行われています。このとき LILO からブー
トするには、ブートに必要なファイル (カーネルと /boot に置かれて
いるファイル群) をすべてシリンダ 1023 以下の範囲に収めておくこと
が大事です。
4.1.9. DOS など
異教徒と思われたくはないんですが、読者のみなさんが迫害しているこの手の
ブツについても一節を設けることにしました。残念ながらハードウェアに付い
てくる設定ツールには、この種の OS でしか動かないものがまだ多いんです。
では行きます。
速度
非常に遅くて良いでしょう。これらのシステムに対して「高速だ」とい
う評判は聞いたことがありませんから、ここに高性能のドライブをあて
がう価値はほとんどありません。マルチタスクでもマルチスレッドでも
ありませんから、 SCSI ドライブのコマンドキューの機能を有利に働か
せることもできません。古い IDE のディスクがあればそれで充分で
しょう。 Win95 や NT のカーネルは一応マルチスレッドをサポートし
ているようですので、理論的には高機能な SCSI デバイスを有効に使え
る可能性もあります。
容量
これらの OS を作っているメーカーには「コードが小さい」という評判
は特に無いようですから、インストールする OS や Windows のバー
ジョンにもよりますが、数 10 MB 程度を用意しておく必要があるで
しょう。古いバージョンの DOS や Windows なら 50 MB あればたいて
いのものは詰め込めるでしょう。
信頼性
はは。「鎖の強さは最も弱い環で決まる」という言葉を聞いたことがあ
りますか？どんな古いドライブでも構わないでしょう。ドライブが壊れ
る前に OS が飛んでしまいますから。きっと誰もがこのパーティション
から、バックアップが重要であることを学ぶでしょう。
別の言葉で言いましょうか。「君の任務はこのパーティションを稼動さ
せ続けることだ。なおこのメッセージは 10 秒以内に自動的に消滅す
る...」
最近、これらの主張の正当性を示せと言われました。でもちょっと待っ
て下さい。まず筆者は DOS や Windows のことを、 OS のひどいマガイ
モノだと言っているわけではありません。法律的な問題も色々と考えな
ければなりません。あー、このいまの 2 文の間に関係があると言うの
は偏執者の戯言です。本当ですって。えー、では代わりに尊敬すべき読
者の皆さんにいくつかのキーワードを差し上げましょう。 DOS
4.0、DOS 6.x、名もないままに消え去ったたくさんのドライブ圧縮ツー
ル...
4.2. 用語の説明
もちろんディスクは速いに越したことはありません。しかし Linux のインス
トールに当たっては、様々なスピードや信頼性のディスクが混在することが珍
しくありません。この文書では性能を「速い」とか「遅い」とか言っています
が、これは粗っぽい分け方に過ぎません。これ以上細かく区別するのは難しい
んです。それでも心に止めておくと良い点はいくつかあります。
4.2.1. 速度
実際には「速度」というのはいくつかの要素が複雑に絡み合って決まっていま
す。例えば CPU 負荷、転送前のオーバーヘッド、ディスクのシーク時間、転
送速度などです。確立した最適なチューニングというものはありません。たい
ていの場合は価格が最も重要な要素になるでしょう。 CPU 負荷は IDE システ
ム以外ではそれほど問題になりません。 IDE システムでは CPU が転送に関与
しますが、 SCSI では CPU 負荷は一般に小さいです。実際の数値に関しては
SCSI についての文書を見てください。ディスクのシーク時間は小さいほうが
良く、通常数ミリ秒程度が望ましいでしょう。 SCSI のコマンドキューが使え
る場合には、コマンドを重ね送りしてバスを常に有効にできるので、シーク時
間はそれほど問題にはならないでしょう。ニューススプールのように小さな
ファイルを大量に含んでいるような特殊な場合には、シーク時間は重要になる
でしょう。
ここでは、二つの主要なパラメータについてもう少し述べます。
シーク時間
これはディスクの読み書きに際して、ヘッドがあるトラックから別のト
ラックへ移動するのにかかる平均時間のことです。このパラメータは数
多くの小さなファイルを扱うような場合に重要になります。スプール領
域などが該当します。また指定されたセクタがヘッドの位置に回転して
くるまでに消費される遅れ時間もシーク時間に含まれます。この遅れは
ドライブの回転速度に依存し、回転速度がドライブの主要なパラメータ
とみなされている理由の一つになっています。通常用いられる値は
4500, 5400, 7200 RPM (rotation per minute: 一分あたりの回転数)
です。回転数が高いものはシークが早くなりますが、高価になります。
また 7200 RPM 動作するドライブは騒音や発熱量が大きくなりがちで
す。この事は巨大なディスクアレイやディスクファームを作るときには
気に留めておく必要があるでしょう。つい最近には 10000 RPM で動作
するドライブも市場に出てきました。この製品では冷却条件が特に厳し
くなっており、エアーフローに関する条件が動作保証に必要になりまし
た。
転送速度
通常 MB/s という単位で記されます。このパラメータは大きなファイル
を扱う場合に重要になります。ライブラリのファイルや、辞書・画像
ファイルなどがこれに当たります。回転数の高いドライブでは転送速度
も回転速度に比例して大きくなります (セクタ密度が一定の場合)。
以上からわかるように、ドライブの性能表を注意深く読むことは重要です。ま
たスペック中の最大転送速度は、オンボードキャッシュからの転送速度で与え
られていることが多く、必ずしもディスクから直接転送するときの速度ではな
いことに注意してください。 ``電力と発熱'' の節も見ておくようにしてくだ
さい。
4.2.2. 信頼性
わざわざ低い信頼性のディスクを欲しがる人もいないでしょうが、古いディス
クは信頼性が低いと思っておくほうが良いでしょう。ところで RAID の用途に
は、いろいろな種類のディスクを混ぜて使うのが良いとされています (関連す
る文書を見てください)。そうしておけば、ディスクの同時クラッシュが避け
やすくなるからです。
今のところ、ファイルシステム全体が故障したという報告は筆者は一つしか聞
いたことがありません。しかし不安定なハードウェアは数多くの障害の原因に
なるようです。
最近では随分ディスクは安くなりましたが、人々はまだドライブの中身の重要
性を過小評価しているようです。より高い信頼性が必要なら、古いドライブは
置き換えて、古い方はスペアとして保存しておきましょう。ドライブが何年に
もわたって連続運転を続けることは特に珍しくはありませんが、最後にドライ
ブを壊してしまうのは電源の on off であることが多いようです。
4.2.3. ファイル
ファイルの大きさの平均値は、ドライブのパラメータを選択・決定するときに
重要な意味を持ちます。たくさんの小さなファイルを扱うときはシーク時間
が、大きなファイルを扱うときは転送速度が重要になります。多数の小さな
ファイルを扱う場合は SCSI のコマンドキューが有利に働きますが、転送速度
に関しては安い IDE のディスクも SCSI にそれほどひけをとりません。
5. いろいろなファイルシステム
歴史とともにファイルシステムへの要請は増えつづけてきました。大きな構
造、大きなファイル、長いファイル名などに対する要求から、巨大な記憶装置
を利用・統合できる、より先進的なファイルシステムが登場してきました。今
日では数多くのファイルシステムを選択できるようになりました。この章で
は、これらのファイルシステムについて詳細に述べたいと思います。
今のところ重点は Linux にありますが、より広い読者に向けた情報も、お寄
せいただければ喜んで追加したいと思います。
5.1. 汎用のファイルシステム
ほとんどの OS には一般用途向けのファイルシステムがあり、日常これが大抵
のファイルに対して利用されています。このようなファイルシステムは許可属
性フラグや保護・復旧など OS の機能を反映したものになっています。
5.1.1. minix
これは Linux が最初に用いたファイルシステムでした。 Linux がまだ minix
マシンに寄生していた頃のことです。これは単純ですが機能に制限が多いの
で、システムのコンパクトさから一部のレスキューディスクに用いられている
のを除き、今日ではほとんど用いられていません。
5.1.2. xiafs と extfs
これらも古く、使われなくなってしまいました。今後はお薦めできません。
5.1.3. ext2fs
Linux の世界で汎用ファイルシステムの標準の地位を確立しているファイルシ
ステムです。 ext2fs は高速で、効率が良く、成熟したシステムです。開発も
まだ継続しており、 ACL や透過圧縮機能などがそろそろ姿を現しつつありま
す。
より詳しい情報は、 ext2fs ホームページ
を見てください。
5.1.4. ext3fs
これは ext2fs の継承者となるものの名前で、近い将来に安定版カーネルに取
り込まれます。 ext2fs に対して多くの機能が追加されていますが、このよう
な過激なアップグレードの後で混乱を生じないよう、名前も変更することにな
ります。既に聞いたことのあるひとは多いでしょうが、ソースコードはまだβ
リリースの段階です。
パッチは Linux.org から
入手できます。
訳注: 2.4.15 から標準カーネルにも入ったようです。
5.1.5. ufs
これは BSD やその派生システムで用いられているファイルシステムです。成
熟したシステムですが、古いタイプのディスクドライブ向けに開発されたもの
で、ジオメトリが分からないと使えません。このファイルシステムは性能を最
適化するために多くのトリックを使っていますが、ディスクジオメトリが様々
な方法で変換されるので、実際の効果はそれほど大きなものではありません。
5.1.6. efs
Extent File System (efs) は Silicon Graphics 社の初期のファイルシステ
ムで、 6.0 以前の IRIX で広く使われていました (それ以降は xfs が使われ
るようになりました)。 xfs への移行をお薦めしますが、 efs もまだサポー
トされていますし、 CD では多く使われています。
ベータ版になったばかりですが、 Linux のドライバも Linux extent file
system ホームページ から入手できます。
5.1.7. XFS
Silicon Graphics Inc (sgi) は、彼らのメインフ
レームグレードのファイルシステムを、 Linux へ移植し始めました。現在彼
らは法律的な厄介ごとを急ピッチで整理している段階なので、ソースはまだ入
手できませんが、これが片づけばソースコードは GPL のもとに提供される予
定です。
現在入手できる情報は、 SGI の XFS project page
からどうぞ。
5.1.8. reiserfs
1997 年 6 月 23 日、 Hans Reiser reiser (at) RICOCHET.NET は、彼が開発
したツリーベースのファイルシステムである reiserfs
のソースコードを web に置きました。このファイ
ルシステムには非常に面白い機能がいくつかあり、また ext2fs よりもずっと
高速であるため、多くの人々が利用するようになりました。おそらくは今年の
年末にリリースされる 2.4.0 カーネルでは利用できるようになるでしょう。
訳注: 2.4.1 から標準カーネルに入ったようです。
5.1.9. enh-fs
Enhanced File System プロジェクトは現在活動していません。
5.1.10. Tux2 fs
これは ext2fs のバリエーションで、電力障害などの突然の割り込みにおける
堅牢性を追加するものです。このような事態が生じた後には、 Tux2 fs は最
近記録された整合性のとれている状態で再起動し、 fsck などのリカバリ動作
を行いません。これを行うため、 Tux2 fs では新たに設計された Phase ツ
リーと呼ばれるアルゴリズムを用いています。
より詳しい情報はプロジェクトのホームページ
にあります。
5.2. Microsoft のファイルシステム
この会社は多くのことに責任がありますが、多くのファイルシステムを作り、
それによって (一番穏やかな言い方でも) 混乱を引き起こしたこともそのひと
つです。
5.2.1. fat
じつは fat には二種類あります。 fat12 と fat16 で、利用しているパー
ティションサイズに依存しています。しかしこれらの違いはごくわずかですか
ら、幸運なら全く違いに気付かずにすむかもしれません。
長所としては、これらは速く、単純で、多くの OS から読み書きアクセスがで
きます。というかそのためだけのものですね。
欠点としては、安全性が低い、許可属性フラグが非常に少ない、拡張性が最悪
に乏しい、などが挙げられます。例えば fat では 2 GB 以上のパーティショ
ンを扱うことができません。
5.2.2. fat32
およそ 10 年たって、 Microsoft は fat の問題に気付きました。そして、
えーと、10 年時代を遡って、このファイルシステムを作りました。拡張性は
まあまあですけどね。
許可属性フラグは少ないままです。 NT 4.0 はこのファイルシステムを読むこ
とができません。 Linux はできます。
5.2.3. vfat
Microsoft は fat32 を公開すると同時に、長いファイル名のサポートを追加
しました。これが vfat です。
vfat タイプでマウントすれば、 Linux は vfat と fat32 のパーティション
を読むことができます。
5.2.4. ntfs
これは Win-NT のネイティブなファイルシステムです。しかし完全な情報が公
開されていないために、他の OS ではほとんどサポートされていません。
5.3. Logging ファイルシステム・ Journaling ファイルシステム
これらは従来とは根本的に異なった方法でファイル更新を扱います。ファイル
の更新情報はログに記録しておき、しばらく後のある時点で、そのログを
checkpoint する (メインの部分に反映させる) のです。
読み出しの性能は、ファイルを直接更新する従来のファイルシステムとそれほ
ど変わりません。書き込みの方は、更新がログに追加されるだけなので、ずっ
と高速です。ユーザに対するインターフェースはこれまでと変わりません。こ
のファイルシステムは信頼性に優れ、またファイルシステムの整合性チェック
が非常に有利になっています。最後に checkpoint を行った以前から存在する
データは正しいとみなせますから、ログだけをチェックすれば良いわけです。
したがって従来のファイルシステムよりもずっと高速になるのです。
logging ファイルシステムはデータと inode の両方の変更を記録します。一
方 journaling ファイルシステムは inode の変更だけを記録します。
Linux ではこのようなファイルシステムに対する選択肢はたくさんあります
が、いずれも製品としてのクォリティは持っていません。開発が止まっている
ものもあります。
o Yggdrasil の Adam Richter はちょっと昔に、圧縮機能を持った log ベー
スのファイルシステムを開発していることをポストしました。しかしこの
プロジェクトは現在止まっています。動作しない段階の版ではあります
が、彼らの FTP サーバから入手できます。 Yggdrasil ftp server
をチェックすれば、特殊な
パッチが当てられたカーネルが見付かるでしょう。
o 他のプロジェクトとしては、 Linux log-structured Filesystem Project
があります。これも残念なことに止
まっています。しかしこのページにはこのトピックに関する多くの情報が
あります。
o また LinLogFS -- A Log-Structured Filesystem For Linux
(以前は dtfs)
というプロジェクトがあり、強化されつつあるようです。まだアルファ版
ですが、このファイルシステムからのプログラム起動が高速化される程度
にまでは完成しています。
o 最後に Journaling Flash File System
を挙げておきましょう。組
み込みのディスクレスシステム向けに設計されたもので、例えば Linux
ベースの web カメラなどに用いられています。
ext3fs, XFS, reiserfs には logging や journaling の機能があることも触
れておきます。
5.4. リードオンリーのファイルシステム
リードオンリーのメディアも、複雑化してきたファイルシステムの例外である
ことはできませんでした。したがってこの分野にも多くの選択肢があり、頭に
くるようなミスをしてしまうような可能性もあるわけです。
ext2fs も CD-ROM でちゃんとうまく動作しますし、領域の節約になるようで
す。通常のファイルシステムの機能である長いファイル名や許可属性も提供さ
れますし、これらは読み書き可能なメディアに対してコピーするときにも保存
されます。 CD-ROM に /dev をつくることも可能です。
これらの多くは CD-ROM メディアで用いられていますが、最近の DVD でも使
えますし、ハードディスクファイル上に作成した loopback デバイスでも利用
でき、 ROM を焼く前のイメージのチェックに使えます。
Linux にはリードオンリーの romfs もありますが、これはディスク用のもの
ではありませんので、ここではこれ以上は触れません。
5.4.1. High Sierra
これは CD-ROM のフォーマットとしては最も初期に標準となったものでした。
おそらく最終的な合意が成されたホテルの名前に基づいて名づけられたので
しょう。
High Sierra にはごく限られた機能しかなかったので、新しい拡張がなされて
いきました。新しいフォーマットは続々と登場していきましたが、オリジナル
の High Sierra はそれらの共通の母体であり、したがって現在でも広くサ
ポートされています。
5.4.2. iso9660
International Standard Organization でも拡張とその標準化が行われまし
た。 iso9660 規格として知られているものです。
Linux の iso9660 ファイルシステムは High Sierra と Rock Ridge 拡張を両
方サポートしています。
5.4.3. Rock Ridge
短い名前や許可属性がないことに我慢していられる人たちばかりではなかった
ので、 Rock Ridge 拡張がこれらの欠点を補うべく早々に登場しました。
5.4.4. Joliet
Microsoft も標準拡張のゲームから遅れを取らないようにすべく、 CD-ROM
フォーマットを拡張して国際化の機能を付加しました。彼らはこれを Joliet
と名づけました。
Linux はこの規格を 2.0.34 以降のカーネルでサポートしています。この機能
を用いるには NLS を有効にする必要があります。
5.4.5. 閑話
Joliet は Chicago 郊外の町です。映画 "Blues Brothers" で Jake が収監さ
れていた刑務所があることで知られています。 Rock Ridge (ISO 9660 に対す
る UNIX 拡張) は、映画 "Blazing Saddles" に出てくる (架空の) 町にちな
んで名づけられました。
5.4.6. UDF
DVD が 18 GB もの容量とともに登場すると、世の中にはまた別のフォーマッ
トが必要になりました。今度は野心的にも Universal Disk Format (UDF) と
いう名前がつけられました。これは iso9660 を置き換えようとするもので、
DVD にはこれが用いられるようになるでしょう。
現在のところでは標準カーネルではサポートされていません。しかし Linux
用の UDF driver プロジェクト
が進行中です。パッチと文
書とが入手できます。
詳しい情報は Linux and DVDs の
ページからどうぞ。
5.5. ネットワークファイルシステム
ディスクをローカルな (あるいはグローバルな) ネットワークに公開すること
を可能にするようなネットワーク技術もたくさん存在します。これはこの
HOWTO の目的からするとおまけ的な話題ですが、まあローカルなディスクと一
緒に利用することもできるので、簡単に網羅しておきます。でもこれは誰かが
別の HOWTO に仕立ててくれるのが一番いいでしょうね...
5.5.1. NFS
あるマシンのファイルスペースを他のマシンからマウントさせるための技術と
して、もっとも初期からあるものです。 NFS には性能からセキュリティにい
たるまで数多くの問題が存在しますが、しかし確立された技術であることも間
違いありません。
5.5.2. AFS
これは大きなネットワークで有効にファイルを共有するためのシステムです。
学術的なプロジェクトとしてスタートしましたが、現在では Transarc
によって販売されるようにもなっています。彼ら
のホームページから詳細が得られるはずです。
MIT の Derek Atkins は AFS を Linux に移植し、また Linux AFS mailing
List linux-afs@mit.edu を準備してくれました。このメーリングリストは公
開されています。メーリングリストへの参加希望は linux-afs-
request@mit.edu まで。またバグの報告は linux-afs-bugs@mit.edu へ送って
ください。
重要: AFS は暗号化技術を使っているので、アメリカ国外への持ち出しは許可
されていません。
Transarc を保有する IBM は、最新の Linux 向けクライアント・サーバの公
開をアナウンスしました。
Arla はフリーな AFS の実装です。詳しい情報やドキュメントは Arla
homepage を参照してくださ
い。
5.5.3. Coda
AFS と似たネットワークファイルシステムも準備中で、これは Coda
という名前が付いています。これは AFS より堅
牢性・耐障害性に勝るよう設計され、モバイル動作や、切断動作にも対応して
います。今のところはあまり性能が出ていませんし、 AFS が備えている (ま
た ARLA が備えはじめている) 管理用の適切なツールがありません。
5.5.4. nbd
Network Block Device ( は Linux 2.2 以降で利用でき、
非常に優れた性能を持っているそうです。興味深いことには、これは RAID (
後述) と組み合わせることができるのだそうです。
5.5.5. enbd
Enhanced Network Block Device (enbd)
は nbd を改良しようとしているプロジェクトで、 block 単位でジャーナルさ
れたマルチチャネル通信・内部フェイルオーバー・チャネル間の自動負荷分散
などの機能を導入しようとしています。
想定されていた利用法は、ネット越しの RAID 用途です。
5.5.6. GFS
Global File System はワイドエリアネットワー
クでのストレージを目的として設計された新しいファイルシステムです。現在
はまだ初期段階で、より詳しい情報がまた登場するでしょう。
5.6. 特殊なファイルシステム
一般的なファイルシステムに加え、より特殊なシステムも多数存在します。よ
り高い性能や、様々な機能を提供します。ただし通常は他の点とのトレードオ
フによってですが。
5.6.1. tmpfs と swapfs
一時的に利用するための高速なファイルストレージとして、 SunOS では
tmpfs というものが提供されています。 NeXT の swapfs もほぼ同様のもので
す。これは ufs に宿命的に存在していた速度の遅さを克服するもので、ファ
イルデータのキャッシュとコントロール情報をメモリに置くものです。した
がってこのようなファイルシステム上にあるデータは再起動時には失われま
す。ですから主に /tmp 領域に向いています。 /var/tmp のデータは再起動し
たときにも残っている必要がありますから、こちらには使ってはいけません。
SunOS では tmpfs に対するチューニングはほとんど行うことができません。
また総ファイル数はマシンの物理メモリによって制限されます。
Linux にもカーネルバージョン 2.4 以降に tmpfs 機能が加わり、仮想メモリ
ファイルシステムのサポート (以前の shm fs) も可能になりました。カーネ
ルバージョンが古いと、特定の環境下では tmpfs によってシステムが固まる
ことがあります。 2.4.6 以降を用いるようにしてください。
5.6.2. userfs
user file system (userfs) は従来のファイルシステムに様々な機能追加を可
能にするものです。例えば FTP ベースのファイルシステムや圧縮機能
(arcfs)、高速な prototyping、他にもいろいろなものがあります。詳しい情
報は userfs homepage をチェック
してください。
5.6.3. devfs
ディスクが追加されたり削除されたり故障したりすると、残りのディスクの
ディスクデバイス名が変更されてしまうことが良く起こります。例えば sdb
が故障すると、 sdc だったものが sda になり、 sda だったものが sdc に
なってしまったりします。なお hda の場合には、 hdb などは変化しません。
同様に追加の際にも変化は起きません。
SCSI ID 0 が sda になるという保証はありません。ですからディスクを大き
な ID 番号に順に追加しても、以前からのデバイス名が保存されたまま新しい
デバイス名で追加されるとは限りません。 SCSI のドライバには、 ID 0 から
小さい順に割り当てを行うものと、検索された順に割り当てを行うものが共存
しているからです。同様に SCSI ホストアダプタの追加の際にも名前の変更が
起こる可能性があります。
一般には、デバイス名は見付かった順に割り当てられます。
この問題の原因は、デバイスファイルに対するメジャー番号・マイナー番号に
用いることのできるビット桁数が制限されていることにあります。これらは
/dev ディレクトリに存在し、番号づけと割り当ての情報は man MAKEDEV から
得られます。現在のところ、この問題解決には 2 つのアプローチが取られて
おり、それぞれ異なる開発段階にあります。
scsidev
これはドライブとそれらの位置に関する情報のデータベースを作成して
動作します。詳しい情報は man scsifs や scsidev home page を
チェックしましょう。
devfs
これはもう少し長期的展望に立ったプロジェクトで、デバイスの番号づ
けそのものを止め、 /proc のような動作をするカーネルファイルシス
テムとして /dev ディレクトリを使おう、というものです。より詳しい
情報が入手できるようになったら、今後この文書に追加します。
5.6.4. smugfs
色々な理由から、 2 GB 以上の大きさのファイルを作ることは現在では困難で
す。この制限を乗り越えようと試みているファイルシステムの一つが smugfs
です。これは非常に高速でシンプルなものです。たとえばディレクトリはあり
ませんし、ブロック割り当ても単純です。
圧縮された tar 形式でソースコード
が入手できます。
これは 2.1.85 版のカーネル用のものですが、多少作業をすれば最近のカーネ
ルに対応させることも可能でしょう。バージョン番号が小さい (0.0) ことか
ら、取り扱いには極めて注意が必要かと思われます。
5.7. ファイルシステムのお勧め
まさに選択肢のジャングルですが、通常はディストリビューションで提供され
ている汎用のファイルシステムを用いるのが良いでしょう。 ufs を使うと
き、 tmpfs のようなものが同時に利用できる場合は、まず汎用のファイルシ
ステムからはじめて、容量がどのくらい必要かを見積もり、それに応じて
tmpfs が必要とする RAM を買い足しましょう。さもないと原因不明のクラッ
シュに見舞われ、時間を無駄にすることになります。
デュアルブートマシンで、それぞれの OS でデータを共有する必要がある場合
に最も簡単なのは、適切なサイズのパーティションを fat でフォーマットす
ることです。大抵のシステムはこのファイルシステムを安全に読み書きできる
はずですから。ただし fat パーティションには 2 GB の制限があるのを忘れ
ないように。
ファイルシステムの相互可搬性に関する詳細は、 file system
のページを
チェックしてください。なおこのページは今後 file system
と Kragen's Amazing List of
Filesystems が継承するようで
す。
このガイドは HOWTO にまとめられている最中です。完成したら、ここからも
リンクする予定です。
ドライブが故障したときに、デバイス名の変更によってシステムが災厄に襲わ
れないようにするためには、システムの検索順序を調べ、ルートファイルシス
テムを hda か sda に保つようにし、 ZIP ドライブのようなリムーバブルメ
ディアを検索順の最後に配置しましょう。
6. ディスク関連技術
手持ちのデバイスを最大限利用するにはどうすればよいかを判断するには、ど
んな技術が現在利用可能で、それらはどのようなものなのかを知る必要があり
ます。毎度ながら、速度や信頼性、能力、柔軟さ、使い易さ、複雑さなどなど
に一長一短があります。
以下に記述されている技術を組み合わせる方法も数多くあり、性能や信頼性を
向上させることができます。ただし複雑になるという代価も当然生じますが。
6.1. RAID
この方法は、複数のディスクを並列に使うことによってアクセス時間やデータ
転送速度を向上させ、ディスクシステムの信頼性と速度とを高めようというも
のです。チェックサムやミラーリングが信頼性向上の手法として用いられてい
ます。大きなサーバでは有効な方法ですが、シングルユーザのシステムには過
剰な機能でしょう。既にたくさんのディスクがあるような場合には考慮しても
良いかもしれません。他の文書や FAQ なども見てください。
Linux で RAID を実現するには、カーネルの md モジュールを使ってソフト的
に行なう方法、 Linux でサポートされているコントローラ (PCI-to-SCSI) を
使ってハードウェア的に行なう方法、 SCSI-to-SCSI のコントローラを使う方
法の三つがあります。ハード的な方法のほうが高速ですし、おそらく安全でも
あるでしょう。しかしお金もかかります。
Linux で利用できるハードウェア RAID に関するまとめは Linux Consulting
で見ることがで
きます。
6.1.1. SCSI-to-SCSI
SCSI-to-SCSI のコントローラは、通常一つのキャビネットにドライブと一緒
に収められており、コントローラのもう片方の SCSI バスでコンピュータに繋
ぐようになっています。つまりキャビネット全体が、大きく高速な一つの
SCSI ドライブとして見え、特別な RAID ドライバは必要としないのです。欠
点としては、キャビネットとコントローラを繋ぐ SCSI バスがボトルネックに
なることが挙げられます。
巨大なディスクファームを作る人たちにとっての大きな問題は、 /dev ディレ
クトリに置かれる SCSI ドライブのエントリには制限があるということです。
このような場合 SCSI-to-SCSI を使えばエントリをあまり消費しないですみま
す。
通常はフロントパネルから、あるいはオンボードのシリアルインターフェース
に接続した端末から設定が行えるようになっています。
このようなシステムを作っているメーカーとしては CMD
や Syred などがあります。
web ページにいくつかのシステムに関する説明があります。
6.1.2. PCI-to-SCSI
PCI-to-SCSI コントローラは、名前からもわかる通り高速な PCI バスを使う
ので、 SCSI-to-SCSI のようなボトルネックに悩まされずにすみます。これら
のコントローラには特殊なドライバが必要ですが、 RAID の設定をネットワー
ク越しに行うような手段もあるので、管理は単純化できます。
Linux でサポートされている PCI-to-SCSI ホストアダプタの製品ラインアッ
プは、現在はまだあまりたくさんはありません。
DPT
もっとも歴史があり、またもっともラインアップの充実したコントロー
ラは DPT から入手できます。 SmartCache
I/III/IV と SmartRAID I/III/IV コントローラのファミリがありま
す。これらのコントローラは、標準カーネルの EATA-DMA ドライバでサ
ポートされています。 DPT のホームページ に
も有益な情報があります。製品の情報だけでなく、 RAID や SCSI に関
する一般的な解説も読むことができます。
DPT コントローラ用ドライバ (EATA* ドライバ) の著者が書いたページ
には SCSI と DPT
に関するより詳細な
情報があります。
DPT のコントローラは最速というわけではありませんが、長く使われて
おり、その信頼性は証明済みです。
DPT コントローラのメンテナンスツールは、現在のところ DOS/Win で
しか動作しません。したがって小さな DOS/Win のパーティションを
作って、いくつかソフトを入れておく必要があります。またこの RAID
システムを管理するには、システムを Windows でブートしなければな
らないわけです。
ICP-Vortex
ごく最近追加されたコントローラのシリーズで、情報は ICP-Vortex
にあります。五つの独立なチャンネルを
もち、 i960 チップを用いた非常に高速なハードウェアになっていま
す。 Linux のドライバはメーカー自身によって書かれており、もちろ
ん Linux をサポートすることも表明されています。
ICP-Vortex は Linux 用のメンテナンスソフトウェアを供給しており、
RAID システムの設定や管理に他の OS で再起動する必要はありませ
ん。したがってダウンタイムが少なくて済みます。
Mylex DAC-960
つい最近追加されたもので、現在ベータ版の初期段階です。詳細な情報
やドライバは Dandelion Digital's Linux DAC960 Page
. から入手してくだ
さい。
Compaq Smart-2 PCI Disk Array Controllers
これもごくごく最近追加されたもので、現在 Smart-2
用のドライバは
ベータリリースの段階です。
IBM ServeRAID
IBM は彼らのドライバ
を GPL で公開しています。
6.1.3. ソフトウェア RAID
普通のディスクとコントローラを使ってソフトウェアで RAID を実現する手法
は多くの OS で可能です。価格コストは低く、 raw ディスク I/O を非常に高
速にできます。これは CPU にかかる負荷が極めて大きいので、導入しようと
しているマシンの制限が I/O ではなく CPU にある場合は、後述するハード
ウェア的な PCI-to-RAID コントローラを利用するのが良いでしょう。
ソフトウェア RAID とハードウェア RAID との導入コスト、性能、そして特に
信頼性に関する比較は、非常に古くから続いている話題です。 Linux の信頼
性に関しては、現在では非常に優れているとされています。
Linux における現在の ソフトウェア RAID プロジェクトは md (multiple
devices) です。これは RAID 以外の機能もたくさん備えているので、後ほど
より詳しく紹介します。
6.1.4. RAID のレベル
RAID には何段階かのレベルがあり、それぞれ異なった機能を持っています。
ここではこれらの内容について簡単に説明します。 Software RAID HOWTO
にはもっとずっと詳細
な情報があります。 RAID に興味を持たれた方は参考にしてください。
o RAID 0 はデータの冗長性を全く持ちません。しかし入出力のスループット
は最高です。それぞれのデータは複数のドライブに分割して書き込まれる
(ストライピングといいます) ので、 read/write が並行して同時に行われ
ます。その代わり、ひとつのドライブだけでも壊れてしまうとすべての
データが失われます。バックアップのことはもう言いましたよね？
o RAID 1 はデータの冗長性をもっとも原始的な手法で実現しています。すべ
てのドライブのデータを 2 重化しているのです。もちろん容量の点では非
常に損なのですが、アクセス速度の点からは多少の利点があります。デー
タをアクセスする際に、先にシーク動作を完了したドライブからデータが
読み取られるからです。転送速度はドライブが一台の時より速くはできま
せん。ドライブそれぞれから 1 トラックずつ読み込めば、多少は読み出し
転送は速くなるかもしれませんが。
もしドライブが 2 台しかない場合は、この方法がデータ冗長性を持たせる
唯一の方法となります。
o RAID 2 と 4 はそれほど一般的ではないので、ここでは省略します。
o RAID 3 は 2 台以上のディスクを使い、データを RAID 0 のストライピン
グのような形で記録します。また冗長性を保持するディスク (redundancy
disk) が追加されており、データディスクからのデータの XOR sum を保持
するようになっています。もし redundancy ディスクが故障しても、シス
テムは何事もなかったように動作できます。データディスクのどれかひと
つが故障しても、その上にあったデータは残りのデータディスクと
redundancy ディスクのデータとから計算できます。ただし同時にどれか 2
台の故障が起きた場合は、 RAID 上のすべてのデータは失われます。
RAID 3 は、少なくとも 2 台のデータディスク (redundancy ディスクを入
れると 3 台のディスク) がなければ意味がありません。理論的には組にで
きるディスクの台数に制限はありませんが、台数が増えると故障の確率も
増加していきます。通常一つの RAID セットあたりのディスク台数は 5 か
ら 7 台程度になっていることが多いでしょう。
RAID 3 で冗長性情報の保存されているディスクはある特定のものになって
います。この情報は、どこかのデータディスクに書き込みが行われるたび
に更新しなければなりませんから、 RAID 3 セットの書き込み性能は
redundancy ディスクの速度によって律速されることになります。一方
RAID 3 の読み込み性能は、データディスクの台数と同じ台数構成の RAID
0 と等しくなります。どれかのディスクが故障して、そのディスクに保存
されていたデータを冗長性情報から再構成しなければならない場合は、性
能は非常に低下します。すべてのディスクで読み込みを行い、 XOR 計算を
行って失われた情報を回復しなければならないからです。
o RAID 5 は RAID 3 と似ていますが、冗長情報が RAID セットのすべての
ディスクに少しずつ保存されています。これによって書き込み性能が向上
しています。負荷がすべてのディスクに分散するからです。
RAID 0 や 1 を他のレベルと組み合わせて使うこともできます。様々な組み合
わせが可能なはずですが、筆者が見たことがあるのは 2〜3 種類です。これら
は上に紹介した RAID の各レベルよりもずっと複雑なシステムになります。
RAID 0/1 はストライピングと二重化を組み合わせたもので、非常に速い転送
速度とシーク速度、およびデータ冗長性が得られます。欠点は消費するディス
ク容量が大きいという点と、先程触れたようにシステムが複雑になってしまう
という点です。
RAID 1/5 の組み合わせは冗長度確保における RAID 5 の優位性とシーク速度
における RAID 1 の優位性を組み合わせたものです。冗長性は RAID 0/1 に比
べて改善されますが、それでもディスク消費はそれなりになります。このよう
なシステムは通常 6 台以上のドライブから構成されます。複数のコントロー
ラや SCSI チャンネルが利用される場合もあるでしょう。
6.2. ボリューム管理
ボリューム管理 (volume management) はパーティションやディスクの容量が
固定されていることによる制限を (他に使えるファイル領域がある場合に) な
くしてしまうものです。新しいディスクをシステムに追加すれば、このドライ
ブの領域をファイルシステムの好きな部分に追加できるのです。また壊れかけ
ているディスクからデータを別のドライブに移して、災害を避けたりすること
もできます。
Veritas によって開発されたシステムが logical
ボリューム管理システムのデファクトスタンダードになっているようです。
現在のところでは、 Linux にはボリューム管理の分野は欠けています。
仮想パーティションシステム (Virtual Partition System) プロジェクトであ
る VPS は、 IBM の AIX システムに
あるボリューム管理機能の多くを再実装しようというものです。しかし残念な
がらこのプロジェクトは現在停止しています。
別のプロジェクトとしては Logical Volume Manager
というものもあります。 HP のプロジェク
トに似たものです。
6.3. Linux md カーネルパッチ
Linux Multi Disk (md) はブロックレベルの機能を数多く提供します。開発の
水準は方式によって異なります。
RAID 0 (ストライピング) と concatination (連結) とは非常に安定してお
り、製品レベルのクォリティです。 RAID 4 と RAID 5 もかなり成熟していま
す。
いくつかのレベルを組み合せることも可能で、例えばストライピング (RAID
0) させたドライブ 2 台からなる組を二つ用意して、それらを互いにミラーさ
せる (RAID 1) こともできます。 RAID 0 の速度と RAID 1 の信頼性とを組み
合せることができるわけです。
RAID に加えて、 md システムではブロックレベルのボリューム管理システム
を提供しています (アルファレベルですが)。これはブロックレベルで行われ
るので、任意のファイルシステムと組み合わせることができます。 FAT と
Wine でさえも利用が可能です。
どのドライブを組み合せればすべてのドライブを並列動作させられるか、充分
に考えてください。報酬は性能の向上と故障率の低下という形で戻ってくるは
ずです。より詳しくは md に付属の文書を読んでください。
残念ながら Linux のソフトウェア RAID は 2 つに分岐してしまっています。
古い安定版の 0.35 と 0.42 は Software-RAID HOWTO
に公式版とし
て文書化されています。新しく、少々不安定な 0.90 のシリーズは、
Software RAID HOWTO
に非公式版の文書があります。こちらの作業は進行中です。
patch for online growth of ext2fs も開発初期の段階で
すが入手可能です。また関連作業が Sourceforge の the ext2fs resize
project で行われています。
ヒント: うまく動かない場合は、 persistent-block フラグをセットし忘れて
いないか確認して下さい。今のところ最上のドキュメントはソースコードで
す。
6.4. 圧縮
ディスクを圧縮するか、それともファイルを圧縮するのかは、ファイルを壊し
てしまう危険性を中心的な争点として、現在でも活発に議論されている内容で
す。新しいものが好きなシステム管理者にはいくつかの選択肢があります。
カーネルモジュール、外部ライブラリへのパッチなど色々な手法が存在します
が、それらの大部分には書き込み不可といったような各種の制限がまだ残って
います。開発は急ピッチで進められており、この文書が出るころには間違いな
くより高機能なものが出ているでしょう。常に言えることですが最新版を
チェックするようにしてください。ここにはいくつかのポインタのみを示しま
す。
o DouBle 形式のファイル圧縮。ただしまだいくつかの制限があります。
o Zlibc。ファイルがロードされるとき、その場で透過的な圧縮／伸展を行う
ものです。
o カーネルモジュール。他の OS で用いられている圧縮ファイルや圧縮パー
ティションを読むことができます。ただしいまのところはほとんどのシス
テムが読み取り専用です。
o dmsdos 現在のバージョ
ン(0.9.2.0) は DOS や Windows で用いられている圧縮オプションの多く
に対応しています。まだ完全ではありませんが、作業は進行中で、どんど
ん新しい機能が追加されています。
o e2compr は ext2fs に圧縮機能拡張を行うパッケージです。まだテスト段
階で、したがって主に興味を持っているのはカーネルハッカー達ですが、
近いうちに安定し、広く用いられるようになるでしょう。詳しい情報は
e2compr homepage を見てくださ
い。速度も安定性も良好である、というレポートをもらっています。
6.5. ACL
アクセスコントロールリスト (Access Control List: ACL) はユーザによる
ファイルアクセスをユーザーベースでより細かく管理するものです。従来用い
られてきた所有者・グループ・その他 (ディレクトリリストに出る drwxr-xr-
x) を置き代えることを目的としています。まだ Linux では利用できません
が、 ext2fs にはすでに開発の足掛りが用意されているので、カーネル 2.3
では使えるようになるのではないでしょうか。
6.6. cachefs
これはハードディスクの一部分を CD-ROM などの遅いメディアのキャッシュと
して利用しようというものです。 SunOS で使えますが、 Linux ではまだで
す。
6.7. 透過 (Translucent) ファイルシステム・継承 (Inheriting) ファイル
システム
これは書き込み時コピー (copy-on-write) のシステムで、書き込みデータは
もとのソースが置かれていたのとは別のシステムに送られますが、通常のファ
イル空間にあるように見えるのです。したがってこのファイル空間はオリジナ
ルのデータを「継承」することになり、また「透過」的な書き戻しバッファを
ユーザごとに別々にできます。
いろいろな応用が考えられます。
o CD-ROM live ファイルシステムが更新可能になり、柔軟・高速になりま
す。領域も節約できます。
o 新しいユーザに対するスケルトンデータを用意しておき、オリジナルデー
タを一ヶ所に保持しておくことで容量を節約できます。
o 開発プロジェクトを平行して行うとき、それぞれのユーザが他のユーザに
影響を与えず、ローカルにシステムを変更できます。
SunOS はこの機能を持っており、 Linux でも開発中です。 Inheriting File
System (ifs) という古いプロジェクトもありましたが、これは停止してしま
いました。現在のプロジェクトは md システムの一部となるもので、ブロック
レベルでの透過性を提供しています。したがってどんなファイルシステムにも
適用できます。
transluent ファイルシステムについてのためになるページ
が Sun によって公開されてい
ます。
なお Clearcase (現在は Rational が保有) が、
彼らの UNIX ファイルシステムによって、ソフトウェア設定の管理に
translucent ファイルシステムを開発・普及させたことは知っておいて良いで
しょう。
6.8. トラックの物理的配置
ここで示すトリックは、かつてドライブが遅くて容量も小さかった頃、そして
ファイルの大きさを見てからファイルの実際の配置を決めるようなファイルシ
ステムがもてはやされていた頃、にはとても重要なものでした。しかし速度が
非常に向上し、ドライブやコントローラでのキャッシュが大きく賢くなった現
在ではそれほどの意味はなくなってきています。
しかし今日においても多少の性能向上の余地は残されています。そして世界制
覇が近づいた今日でさえも、これを早期に達成するにはわれわれは持ち得るす
べての技を使わなければならないのです！
この手法の意味を理解するためには、現在では失われてしまった知識「セクタ
の位置によってディスクの性質がどのように変わるのか」を理解する必要があ
ります。ディスクの回転中心から離れたトラックではデータの転送速度は速く
なります。また中間のトラックを起点／終点とするシークは、内側から外側、
外側から内側へのシークよりも速いでしょう。
ほとんどのドライブは一定の角速度で回っており、また各トラックにおける
データの線密度はだいたい一定になっています。これはすなわち、外側のト
ラックでは内側のトラックに比べてずっと速い転送が行われるということで
す。したがって大きなライブラリなどを置くのに適しています。
最近のディスクでは論理的なジオメトリマップを使っているものもあります。
これは実際の物理的なマップ (ドライブそのもののマップ) とは異なっている
ため、「真ん中辺の」トラックの見当をつけるのが少々難しくなるかもしれま
せん。
ほとんどの場合はトラック 0 が最も外側のトラックであり、多くの人々がこ
の仮定を用いています。しかし、この事には何の保証もないことも心に留めて
おく必要があります。
内側
セクタの転送速度は遅くなります。またシークの起点／終点になる場
合、シーク動作は遅くなります。
この部分は高い性能を必要としない領域に割り当てると良いでしょう。
たとえば DOS やルートファイルシステム、プリントスプールなどで
す。
中間
セクタの転送速度は一般に内側より速く、またシーク動作も速いです。
この特性はスワップや /tmp、/var/tmp など、頻繁に転送要求が来るよ
うな領域に適しています。
外側
セクタの転送速度は最も速いですが、シークタイムは内側と同じように
遅くなっています。
ライブラリなどの大きなファイルが置かれる領域をここに割り当てると
良いでしょう。
頻繁にアクセスされるセクタをディスクの中ほどに置けば、シークの際のヘッ
ドの平均移動距離を下げ、シークタイムを減らすことができます。このように
するには fdisk や cfdisk を実行してパーティションを真ん中あたりに作っ
たり、あるいは dd コマンドを使ってディスク容量の半分ほどの大きさのファ
イルを作り、その後に頻繁に使われるファイルを作成する、といった方法があ
ります。後者の方法では作業後にダミーファイルを消しておきます。いずれも
空のディスクを使い始めるときの方法です。
後者の方法はニューススプールに使うと良いでしょう。データファイルが置か
れる前に、ディレクトリ構造を中ほどのトラックに置くのです。この作業に
よって、多少ですがフラグメンテーションが減る効果も期待できます。
このちょっとしたおまじないは、普通のファイルシステムでも RAID システム
でも使えます。 RAID では、真ん中当たりのセクタを計算するのが (不可能と
までは言いませんが) ちょっと難しいかもしれません。最新の RAID のマニュ
アルを見てみてください。
この作業によって向上する速度はドライブによって異なりますが、でも多くの
場合 50 パーセント程度の向上が見込めます。
6.8.1. ディスクの速度値
ディスクヘッドの機械的機構 (head disk assembly: HDA) の同じものが、異
なるインターフェース (IDE や SCSI など) で共用されることは良くありま
す。したがって機械的な値はだいたい同じになります。今日ではこの機械的な
部分が速度的な限界を決めていますが、たゆまぬ開発努力によって進歩は着々
となされています。さて、ここには二つの主要なパラメータがあります。それ
ぞれミリ秒 (ms) 単位で記述されます。
o ヘッド動作 - 読み書きを行うヘッドが、あるトラックから別のトラックに
移動する速度です。アクセス時間とも呼ばれます。数学が得意な人は、出
発点として可能なすべてのトラックと、到達点として可能なすべてのト
ラックを考え、これらを二重積分してみてください。これは端のトラック
からもう一端までを移動するストロークの 1/3 に等しいことがわかるで
しょう。
o 回転速度 - 必要なセクタに到達するまでの時間を決定します。この時間は
待ち時間 (latency) とも呼ばれます。
ヘッド移動の機構がステッパーモータからボイスコイルに変更されて以降は、
性能の向上は頭打ちになりました。開発のエネルギーは、現在では事実上回転
速度の向上に注力されています。これによる二次的な効果として、転送速度の
向上も期待できます。
以下に典型的な値を挙げておきます。
Drive type
Access time (ms) | Fast Typical Old
---------------------------------------------
Track-to-track <1 2 8
Average seek 10 15 30
End-to-end 10 30 70
非常にハイエンドなドライブでも、アクセス時間においては平均的なドライブ
とたいした差がないことがわかります。ただしステッパーモーターを用いた古
いドライブでは、非常に値は悪いです。
Rotational speed (RPM) | 3600 | 4500 | 4800 | 5400 | 7200 | 10000
-------------------------------------------------------------------
Latency (ms) | 17 | 13 | 12.5 | 11.1 | 8.3 | 6.0
待ち時間 (latency) は指定されたセクタに到達するのに必要な時間ですか
ら、式は非常に簡単で、
latency (ms) = 60000 / speed (RPM)
のようになります。
明らかにこの結果からも、開発努力に対する効果が小さいことがわかります。
しかしここでまるっきり無視した点として、電力消費や熱、ノイズなどの問題
があることも忘れてはなりません。
6.9. Yoke
Linux Yoke Driver の
ベータ版もあります。これは Linux のブロックデバイスを他のブロックデバ
イスにホットスワップ可能なかたちで透過的にバインドするものです。二つの
ブロックデバイス (例えば /dev/hda と /dev/loop0) をバインドすると、片
方のデバイスへ行われた書き込みはもう片方にも行われることになり、両者か
らの読み出しが同じ結果を与えることになります。
6.10. 組み合わせ
OS をレイヤー構造に設計して得られる利点の一つは、要素の組み合せ方法を
いろいろ選べることです。例えば CD-ROM を cashefs でキャッシュし、その
キャッシュはストライピングした 2 つのドライブから構成したりできます。
あるいは、他のマシンから NFS マウントしたボリュームを用いて、キャッ
シュを translucent に設定することもできます。 RAID も何層にも組み合わ
せることができます。非常にシークを高速にし、かつ 3 台のディスクが故障
しても継続動作できるようなシステムを作ることも可能です。組み合わせは無
限ですが、想像力の限界か、あるいは (より重要な要素である) 金銭的な限界
によって制限されるでしょう。
6.11. お勧め
選択可能な組み合せは無限ですが、しかしまずは特殊な機能は使わないで、簡
単な設定からはじめましょう。そして何が必要なのか、最大の性能が必要とさ
れるのはどの部分かを感じとってください。ボトルネックになっているのはア
クセス時間なのか転送速度なのか、などをです。次に各コンポーネントを段階
的に試してみましょう。組み合わせの自由度は極めて大きいです。経験を積ん
で様々なコンポーネントを簡単に組み合わせることができるようになりましょ
う。
RAID を用いるのは通常は良い考えですが、このテクニックを完全に理解して
おくこと、しっかりしたバックアップをとっておくことを忘れないように。
7. 他のオペレーティングシステム
Linux ユーザの多くは自分の PC に複数の OS をインストールしています。こ
れは主に、ハードウェア設定用のプログラムが他の OS (DOS や 各種
Windows) でしか動かないためであることが多いようです。そこで、このよう
な OS をどのように扱えばよいかについて一章を設けました。
7.1. DOS
DOS がオペレーティングシステムの名に値するかどうかの議論はひとまず置い
ておきますが、いずれにしても DOS がディスク操作に関して非常に原始的な
ものであることは確かです。特に問題になるのは、 DOS のいくつかのバー
ジョンでは大きいディスクを扱う際に重大な障害が生じる可能性があることで
す。 Large Disk HOWTO を読んでおくと良いでしょう。各種の問題を避けるに
は DOS は低位トラック領域に置いておくと良いでしょう。
DOS は小さなドライブ向けに設計されてきたものですので、ファイルシステム
(fat) も洗練されたものではありません。 FAT で大きなドライブを扱おうと
すると、あてがわれるブロックのサイズは巨大なものになってしまいます。ま
た FAT ではブロックのフラグメンテーションが起こりやすく、しばらく使う
とシークが頻繁に生じるようになり、実効的な転送速度が低下してしまいま
す。
フラグメンテーションに対する一つの解は、デフラグメントプログラムを定期
的に動作させることですが、これを行う前にはデータをバックアップし、ディ
スクをベリファイしておくことを強くお勧めします。 DOS のすべてのバー
ジョンには chkdsk というディスクを検査するプログラムが付属しています。
また最近のバージョンには scandisk というもう少し良いプログラムもありま
す。デフラグメントを行うプログラムもたくさんあります。バージョンによっ
ては DOS にも defrag というツールがあります。 Norton Utilities は多く
のディスクツールを集めたもので、ディスク向け以外にも色々なツールが付属
してきます。
デフラグの際には hidden 属性を持ったファイルが邪魔になることがありま
す。ベンダによってはこのファイルをコピー防止のキーに使っており、これを
他のディレクトリに移動するとソフトが動かないようにしている場合がありま
す。したがって最近のデフラグツールでは hidden 属性を持ったファイルは移
動しないようにしており、結果としてデフラグメントの効率が低下してしまい
ます。
DOS はシングルタスク、シングルスレッド、その他いろいろな面に関して「シ
ングル」ですから、複数のドライブを使ってもほとんどメリットはありませ
ん。ただし RAID をビルトインでサポートしたドライブコントローラを利用す
る場合は例外ですが。
join や subst といった、複数ドライブ用の設定ユーティリティもいくつか存
在しますが、ほとんどの場合は役に立ちません。最近のバージョンでは削除さ
れたものもあるようです。
DOS に関して手を入れられるところはほとんどありませんが、少ないながら例
外もあります。多くのプログラムでは高速な一時領域を必要としますが、良く
できたプログラムでは TMPDIR や TEMPDIR といったような環境変数を参照し
ます。これら分離したドライブに設定しておくと良いでしょう。
autoexec.bat などで以下のように設定します。
______________________________________________________________________
SET TMPDIR=E:/TMP
SET TEMPDIR=E:/TEMP
______________________________________________________________________
速度の向上だけでなく、フラグメンテーションが減る効果も期待できます。
DOS の fdisk プログラムでは、複数の primary パーティションを削除するの
が難しい、という報告もあるようです。この場合は Linux のレスキューディ
スクから起動し、 Linux の fdisk でシステムを修理してください。
DOS には代替品があることも知っておくと良いでしょう。もっとも有名なのは
Caldera の DR-DOS
です。これは Digital Research の DR-DOS
の直系の子孫です。より使われている DOS にはない、多くの機能 (マルチタ
スクや長いファイル名など) を備えています。
他にもフリーなものとして Free DOS がありま
す。これは開発中のプロジェクトです。一緒に使えるフリーなユーティリティ
もたくさんあります。
7.2. Windows
前節で挙げた点は Windows にも当てはまります。ただし Windows95 ではより
良いディスク管理が行われており、 SCSI のドライブでもその性能を引き出す
ことができています。
ロングファイルネームがサポートされたことは大きいですね。これを Linux
から読むには vfat ファイルシステムを用いてパーティションをマウントしま
す。
ディスクのフラグメンテーションは依然解決していません。この問題は、大き
なプログラムをシステムにインストールする直前・直後にデフラグメントツー
ルを使えばある程度は回避できます。筆者はこの方法を採用していますが、満
足の行く結果が得られています。使っていないファイルを削除して解放領域を
大きくとると、デフラグメントの効果はさらに高くなります。
Windows はスワップドライブを使います。これを別のドライブにすると、ある
程度の性能向上が期待できるでしょう。スワップ領域を複数のオペレーティン
グシステムの間で共有する方法に関する mini-HOWTO もあるようです。
TEMPDIR を指定する、というテクニックは Windows でも有効ですが、すべて
のプログラムがこの設定を見てくれるわけではありません (もちろん見てくれ
るプログラムもあります)。各種コントロールファイルでの設定情報を閲覧す
るには sysedit が便利です。これはたくさんのファイルをオープンし、編集
もできます。ファイルの中のひとつ、 autoexec ファイルに TEMPDIR の設定
を追加できます。
一時ファイルのほとんどは /windows/temp ディレクトリに保存されます。こ
れを変更するには、もう少々テクニックが必要です。これには regedit を使
います。これは強力なコマンドで、システムを不愉快な状態にしてしまうこと
もできます。もっと正確に言うと、そのままの Windows よりももっとずっと
不愉快な状態にしてしまう能力があります。「レジストリデータベースのエ
ラー」が、この悪いニュースを伝えるメッセージです。また多くのプログラム
では、それぞれ独自の一時ディレクトリを定義しており、これがシステム中に
散らばっていることも覚えておいてください。
スワップファイルを分離されたパーティションに置くのは良いアイディアで、
ずっとリスクも低いです。ただしこのパーティションは他のどんな用途にも用
いないようにしてください。たとえ空いているように見えても、です。
現在では ext2fs パーティションを Windows から読むことも可能になりまし
た。 FSDEXT2 でパーティションをマウン
トするか、 Explore2fs
と呼ばれるエク
スプローラ風のツールを使います。
7.3. OS/2
OS/2 には ext2fs のパーティションを読むことのできるドライバがあるそう
です。 Matthieu Willm による、OS/2 用の ext2fs Installable ファイルシ
ステムは ftp-os2.nmsu.edu , Sunsite
,
ftp.leo.org
, ftp-
os2.cdrom.com .
などにあります。
IFS には読み書き両方の機能があります。
7.4. NT
NT はもう少し本格的なシステムです。名前もマーケティング向け (New
Techonology!) ですね。 NT ではソフト的なストライピングといったような、
より洗練された設定ができます。コントロールパネルのドライブマネージャを
チェックしてください。筆者自身は NT を気軽に扱える立場にいないので、詳
細に関する記述は先のことになります。
最近一つ重要な欠点が acahalan@cs.uml.edu から報告されています。 (以下
は Usenet ニュースへのポストを整形しています)
NT ディスクマネージャには重大なバグがあり、複数の (一つ以上
の？) 拡張パーティションを扱うとディスクを破壊してしまいま
す。 Microsoft はこの問題を解決したプログラムを彼らの web サ
イトで配布しています。詳細に関しては knowledge base
のページから検索してくださ
い。この問題は拡張パーティションを使っている Linux ユーザに
も影響します)
最近では Explore2fs
を用いれば、
NT から ext2fs パーティションを読めるようになりました。
7.5. Windows 2000
Windows NT に関する多くの点は、その子孫である Windows 2000 にも当ては
まります。しかし現執筆時では、先に紹介したバグが修正されたかどうか筆者
は知りません。
Windows 2000 は、その祖先と同様に RAID 機能を持っていますが、少なくと
も RAID Toolbox 社 , によれば、バンドルさ
れている RAID には何か欠けたところがあるようで、彼らは自分たちで商用の
代替版を作ったようです。
7.6. Sun OS
Sun OS と Solaris の関係については少々混乱があるようです。単刀直入に言
うと、 Solaris は Sun OS 5.x に過ぎません (Openwindows 等の付属パッ
ケージはありますが)。 Solaris を使っているなら uname -a とすれば現在の
バージョンがわかります。混乱の理由の一部は以下の点にあります。 Sun
Microsystems は以前は BSD 系の OS を使っており、それによそから集めたり
自分達で作ったりしたものを併せて配布していました。 Sun OS 4.x.y までは
このような形でしたが、その後彼らは「将来戦略の選択」をした際に、オフィ
シャルな Unix である System V Release 4 (SVR4) へ切り替えることを決定
したのでした。こうして Sun OS 5 が作成されました。この決定には多くの人
々が不満を感じました。 Sun OS 5 にもいくつかのソフトが追加され、
Solaris という名前で販売されるようになりました。現在は release 7 で、
ごく最近 2.6 から更新されて最新版になりました。バージョン番号には大き
なジャンプがありますが、実際にはマイナーな部分のアップグレードに過ぎま
せん。でもマーケティング的には大きく飛躍したようです。
訳注: 2002 年現在 Solaris 9 がリリースされています。
7.6.1. Sun OS 4
おそらく多くの Linux ユーザに取って馴染み深い OS でしょう。最後のリ
リースは 4.1.4 ですが、各種のパッチが出ています。しかしファイル構造は
FSSTND とは大きく異なっていますので、ディスク配置を行なう際には伝統的
な構造に従う必要があります。 man hier することによってこのディレクトリ
情報が得られます。 man ページの通例のごとく、記述はぶっきらぼうなもの
ですが、出発点としてはよいでしょう。もしそれでもディレクトリ構造に関し
て迷うことがあったら、それは高位に置いてしまえば良いでしょう。
7.6.2. Sun OS 5 (Solaris)
Solaris には Openwindows の下で動くできの良いインストールプログラムが
付属しています。これを用いると CD-ROM からシステムをインストールする前
に、ディスクのパーティション分割とフォーマットが行なえます。ただ、あま
り分割を多くしすぎるとエラーが (しかも 1 倍速の CD-ROM からのインス
トールが長々と続いた後に...) 起こります。筆者は以前働いていたところで
実際このような目にあい、その時はまず一台のドライブにインストールしてか
ら他のドライブへ内容を移すことで回避しました。
デフォルトの設定はなかなかよくできたものですが、スワップドライブの指定
に関してはおかしなところがあります。公式マニュアルではスワップを複数の
ドライブに指定することを勧めていますが (Linux でもそうですね)、デフォ
ルトではひとつのドライブだけを使うようになっています。この点はすぐにで
も改良されるべきだと思います。
Sun OS 5 は一時領域向けに特化したファイルシステム tmpfs を持っていま
す。これは ufs に比べてずっと高速ですが、再起動するとデータは消えてし
まいます。
現時点での筆者の意見は「注意せよ!」です。 Solaris 2.0 で /tmp に大きす
ぎるファイルを作ってしまうと、 "out of swap space" のカーネルパニック
を起こすことがあります。起こったことに関する証拠は RAM ディスクにある
ので、電源を切ったときに他のデータと一緒に失われてしまいます。さらに悪
いのは、ユーザ空間のプロセスがこのカーネルパニックを引き起こすことがで
きるらしいことです。この問題が解決されるまでは tmpfs は使わないことで
す。少なくとも自分の首がかかっているような環境では。
``tmpfs'' にある記述も参考にしてください。
余談: Solaris って言う映画もあります。とっても、と〜っても長くて難解な
SF 映画です。 Solaris (OS のほう) が現われたときには、良くこの映画が引
き合いに出されたものでした...
7.7. BeOS
この OS はごく最近登場したもので、データベースのような機能を持ったファ
イルシステムを備えています。
BFS ファイルシステムの Linux ドライバも開発中で、現在アルファの段階で
す。詳細な情報は Linux BFS page
にあります。パッチもこ
こに置かれています。
8. システムのクラスタ化
この章では複数のマシンを接続して一緒に用いるやり方について簡単に触れた
いと思います。しかしこれは本来大きなテーマなので、もしかしたら別の
HOWTO に分割する方が良いかもしれません(ご意見待つ!)。また正直なところ
をいいますと、このセクションは本 HOWTO 文書の内容からは少々外れていま
す。有名になりたいあなた、この文書を引き継いで新たな文書を書き起こして
みてくれませんか？筆者まで連絡してください。
最近では、コンピュータは恐るべきスピードで時代遅れになってしまいます。
しかし古いマシンでも Linux なら適切な用途に利用できることがあります。
少々古いコンピュータでもネットワークサーバとして有効に使うことができま
すし、これは教育的にも価値があります。このようにローカルなネットワーク
で接続されたコンピュータの集団は多様な形態をとることが可能ですが、この
HOWTO 文書の目的からして、ここではディスクの管理に関してのみを述べたい
と思います。他の人がこの問題を取り上げて独立した文書にしてくれることを
期待しています。
この分野は今日活発な議論がされており、多くの形態のクラスタ化が可能に
なっています。ローカルなネットワークを介しての自動的な負荷分散がその一
つですし、 Scalable Coherent Interface (SCI) といったようなまだあまり
知られていないハードウェアを用いて、複数のマシンを緊密に連携させ、あた
かも一台のマシンのようにすることもできます。大きなマシンに関しては以前
から数多くのクラスタ化が可能になっています。有名な例としては
VAXcluster などが挙げられるでしょう。クラスタ化は通常ディスクドライブ
やプリンタ、端末などの資源を共有するために行われますが、プロセスも資源
として計算機ノード間で透過的に扱うことが可能です。
クラスタ化には特に一般的な定義はありません。ここではユーザに提供する資
源を共有している複数のマシンからなるネットワークを考えることにしましょ
う。これは少々緩い定義ですが、後に変更されて行くでしょう。
最近は Linux でもクラスタ化の機能が提供されています。しかしここではま
ず簡単なローカルネットの構成から説明を始めたいと思います。古くて、他に
は用途の無いようなハードウェアでも、 Linux のような OS で動かせば充分
役に立ちます。
古いマシンの利用法としては、ネットワークサーバ、特に演算性能ではなく
ネットワークのバンド幅で律速されているようなサーバが適しています。例え
ば自宅では以下のような機能を古いマシンを使ったサーバに移動させると良い
でしょう。
o ニュース
o メール
o web のプロキシサーバ
o プリンタサーバ
o モデムサーバ (PPP, SLIP, FAX, ボイスメールなど)
ドライブを NFS サーバからマウントすれば、ワークステーション側でディス
クを節約することもできます。どのディレクトリをマウントすべきでないか
は、やはり FSSTND を参考にしてください。すべてのマシンで共有すべきディ
レクトリの候補としては /usr と /var/spool、あるいは /usr/local などが
挙げられます。でも例えば /var/spool/lpd などは共有させない方が良いで
しょう。
ほとんどの場合は遅いディスクでも充分な性能が得られます。一方サーバ上で
直接ディスクを扱う必要がある場合や、ネットワークが非常に高速な場合に
は、構成を考え直し、速いディスクを使うのが良いでしょう。例えば web
サーバの検索機能やニュースのデータベース検索機能などが該当します。
このようなネットワークはシステム管理の学習にも最適で、将来自分でネット
ワークを作るときに役に立ちます。この点に関しては他の HOWTO 文書から多
くの情報が得られるでしょう。ただし以下のことは気に留めておいてくださ
い。
o IP 番号のリソースは枯渇しかかっているので、できるだけ節約しましょ
う。プライベートネットワーク用の IP 番号を使い、ネットワークサーバ
をルータにして IP マスカレードを用いると良いでしょう。
o ルータをファイアウォールにする場合は、設定によっては自分自身のデー
タさえも外部から閲覧できなくなる可能性があります。
Nyx のネットワークはここでいうところの「クラスタ化」を実現しています。
以下のようなマシンがネットに含まれています。
nyx
これはユーザがログインできる二台のマシンのうちのひとつです。ネッ
トワークサービスも提供しています。
nox (別名 nyx10)
これはユーザが主にログインするマシンで、メールサーバにもなってい
ます。
noc
これは専用のニュースサーバです。ニューススプールは nyx や nox か
らも NFS マウントできるようになっています。
arachne (別名 www)
web サーバです。 web のページが置かれているディレクトリは nox が
NFS マウントしています。
より進んだクラスタ化に関するプロジェクトも進行中です。注目すべきものと
しては以下のようなものが挙げられます。
o The Beowulf Project
o The Genoa Active Message Machine (GAMMA)
クラスタ化を押し進めるには、 SCI のような進んだ技術による接続が必要に
なります。より情報を求める方には、 Dolphin Interconnect Solutions
のページが参考になります。この会社はこの分
野における主役の一人と言えるでしょう。また scizzl
も見ておくといいでしょう。
IMAP を用いた集中型メールサーバは最近非常に増えてきています。ディスク
が充分大きくなってすべてのメールをためこんでおけるようになったため、ま
たディスクが安価になってこれが現実的な選択肢になってきたためでしょう。
残念なことに、メールアーカイブを他のマシンから NFS マウントすると、
IMAP のデータベースが破壊されてしまうことがわかっています。サーバのソ
フトウェアが NFS タイムアウトをうまく扱うことができないからです (そし
て NFS タイムアウトは結構な頻度で起こるものなんです)。メールアーカイブ
は IMAP サーバのローカルなディスクに保存してください。
9. マウントポイント
レイアウトの設計作業を行なう際には、ディレクトリのツリー構造への切れ目
を間違ったところに入れないよう注意する必要があります。この章はそのため
のガイドラインです。この章の内容は FSSTND に大きく依存しますので、独立
させることにしました。将来 FHS が各 Linux ディストリビューションで採用
された暁には、この章は全面的に書き直されることになるでしょう。
ここで述べているのは分割を してもよい 場所であって、分割 すべき 場所で
はありません。適切な判断が重要です。
荒っぽいですが、分割の推薦度合を数字化しておきます。それぞれの値の意味
を示します。
0=分割すべきではない
1=勧められない
…
4=分割するのは有効
5=分割を推奨
リストを短くするために、重要でない部分は削除してあります。
Directory Suitability
/
|
+-bin 0
+-boot 5
+-dev 0
+-etc 0
+-home 5
+-lib 0
+-mnt 0
+-proc 0
+-root 0
+-sbin 0
+-tmp 5
+-usr 5
| \
| +-X11R6 3
| +-bin 3
| +-lib 4
| +-local 4
| | \
| | +bin 2
| | +lib 4
| +-src 3
|
+-var 5
\
+-adm 0
+-lib 2
+-lock 1
+-log 0
+-preserve 1
+-run 1
+-spool 4
| \
| +-mail 3
| +-mqueue 3
| +-news 5
| +-smail 3
| +-uucp 3
+-tmp 5
もちろん調整すべき点は多々あります。例えば自宅で使っているユーザはわざ
わざ /var/spool を分割する必要はないでしょうし、逆にサービスプロバイダ
では是非分割すべきでしょう。重要なのはシステムの利用のされ方です。
問題! なぜ /etc を別パーティションにしてはいけないのでしょう？回答:
ブート時のマウント動作は /etc/fstab ファイルにある情報に従って行われま
す。ですから、もしこのファイルがマウントされていない別パーティションに
あると、「引き出しのカギが引き出しの中に入っている」のと同じ絶望的な状
況になります。 (はいはい、この HOWTO を飽きずに読んでもらうためならな
んでもやりますよん)
10. 考察と配置
まず自分の置かれている立場と、何がしたいのかということから始めましょ
う。家庭のシステムは既にあるハードウェアにインストールされることが多い
でしょう。新しく Linux ユーザになった人は、その既存のハードウェアから
最高のパフォーマンスを引き出したいと思うでしょう。逆にインターネットプ
ロバイダのように、特定の目的のために新たなシステムをセットアップする場
合は、目的に応じて購入するハードウェアを決定する必要があります。できれ
ばこの両極をカバーしたいと思っています。
様々な目的に応じて、ファイルシステムのドライブへの配置も異なってくるで
しょう。例えばマルチユーザで使う大きなマシンなどでは /home を独立した
ディスクに分離するのが良いでしょう。
一般に性能を上げるには、できるだけたくさんのものを別々のディスクに分散
させるのが有利です。しかし一つの SCSI バスに繋げるデバイスの数は限られ
ていますし、コストの問題も絡んでくるでしょう。またパーティションやディ
スクの数が増えるにつれて管理が面倒になるという点も重要です。
10.1. 自宅のシステム
最近の安価なハードウェアを使えば、それほどお金をかけなくても自宅に大き
なシステムを構築できるでしょう。有名なサイトの一年前のサーバマシンと張
りあえるくらいものもそれほど難しくないはずです。多くの人が古くて余った
ディスクでサーバを構築する一方 (この HOWTO が生まれるきっかけもこれで
した)、 40 GB 分のディスクを買いそろえることができる人も少なくはないで
しょう。
でもサイズの見積もりが必要な人もまだいるでしょうから、以下にいくつかの
目安を挙げておきます。
Linux を試す
Linux はシンプルにできていて、試すだけならハードディスクも必要あ
りません。ブートフロッピーさえあれば、あなたの持っているハード
ウェアで Linux を動かしてみることができます。もし使っているハー
ドウェアが特殊で標準のカーネルが動かない場合でも、対応したブート
ディスクが用意されているはずです。最悪の場合でも、お使いのシステ
ムに適応したカーネルが構築できるまでの環境は整っているはずです。
Linux で学ぶ
OS について学ぶには Linux は最適です。関連文書が山ほどあります
し、ソースを見ることもできます。ドライブ一台に 50 MB ほどの容量
があれば、シェルを起動し、良く使われるコマンドやユーティリティを
入れておくには充分でしょう。
Linux で遊ぶ
趣味として Linux を扱ったり、学習をさらに進めるためには、もう少
し多くのコマンドやユーティリティが必要になるかもしれません。しか
しドライブは相変わらず一台、 500 MB ほどあれば OK です。ソースや
ドキュメントも充分入れておけるはずです。
Linux で仕事する
プログラム開発や、趣味でも本格的な利用となると、もう少し容量が必
要になります。この頃になるときっとメールやニュースを利用するよう
になっているでしょうから、そのためのスプール領域が大量に必要にな
ります。各種のタスクに別々のドライブを割り当てることが有効になり
ます。この段階ではきっと複数のドライブを利用するようになるでしょ
う。ドライブの必要量を計算するのは難しいですが、 2〜4 GB あれば
良いのではないかと思います。小規模ならサーバでもこれだけあれば大
丈夫でしょう。
Linux をサーバにする
サーバと言ってもメールサーバからサービスプロバイダまで様々です。
メインのシステムには 2 GB あれば良いでしょう。その後、サービスに
応じて容量やドライブを足して行きます。コストが主な制限になってく
るでしょうが、「サービス」プロバイダであり続けるためには、ディス
クを追加できるように資金には余裕を持っておくことです (そうしてい
ないところも多いようですが)。
本格的に利用されるマシンは皆そうですが、サーバも基本的には割り当
てられたリソースを一杯一杯になるまで使いきってしまうものです。そ
してサーバの場合は、 CPU よりも IO によって律速される場合が多い
です。
有線でも無線でも、ネットワークの技術はどんどん安価になってきてい
ますから、これからの時代にはホームユーザーがネットにつないだサー
バは、すぐに多かれ少なかれ「つなぎっぱなし」になってしまうでしょ
う。
10.2. 各種サーバ
大きなタスクをいくつも走らせるようになると、大きな容量のドライブが必要
になり、それぞれ専用のエリアを作らなければならなくなります。可能ならば
ドライブは別々に分けましょう。この文書の付録には小さな部門用のサーバ (
ユーザ 10〜100 人) のセットアップの詳細も付けておきました。ここではハ
イエンドのサーバについての知識を述べておきます。一般的には RAID を積極
的に用いるべきです。速度や信頼性の面だけでなく、ディスクの追加が多少楽
になるからです。ここで述べる内容は、今までに述べたことを補うものである
と思って下さい。
人気のあるサーバサイトというのはすぐに生まれるものではなく、時間ととも
に成長し、その過程でディスク容量やネットのバンド幅がだんだん必要になっ
ていくものです。このようなサーバを運用している場合、それぞれのタスクで
管理しているデータを丸ごと一つの SCSI ドライブ (またはドライブアレイ)
にあてがっておくのも良い考えです。こうしておけばコンピュータ本体が故障
した場合にデータを移動できるからです。ただしドライブをコンピュータ間で
移動するのはそれほど単純なことではなく、うまく動かない可能性があること
も注意しておいてください。特に IDE の場合は問題の発生率が高くなるかも
しれません。ドライブアレイのデータを正しく再構成する際にも注意が必要で
す。 fstab ファイルやそれぞれのドライブの SCSI ID を紙に書いて保存して
おくと良いでしょう。
10.2.1. ホームディレクトリ
まずドライブが何台必要かを見積もりましょう。 2 台以上ならば RAID を使
うことを強くお勧めします。 RAID を利用しない場合は、ハッシュ的なアルゴ
リズムを使うなどして、ユーザをそれぞれのドライブに振り分ける必要があり
ます。例えばユーザ名の最初の 2 文字などを使うと良いかもしれません。
jbloggs というユーザなら、ホームディレクトリは /u/j/b/jbloggs となりま
す。ここで /u/j は実際のドライブへのシンボリックリンクで、各ドライブへ
の負荷を分散させるように定めます。
10.2.2. アノニマス FTP
サーバ機能でも良く利用される基本的なものです。良いサーバというものは、
良好なメンテナンスがされており、ドキュメントが整備されていて、更新が速
く、そして世界のどこにあろうが非常に有名になるものです。良い例として
は、巨大なサーバ ftp.funet.fi などが挙げられるで
しょう。
このとき問題になるのは CPU ではなく、通常はネットワークのバンド幅で
す。容量を見積もるのは難しく、どの程度の規模にするかやサービスに対する
姿勢によるところが大です。例えば ftp.cdrom.com
の巨大なアーカイブは、 *BSD マシンに 50 GB のディスクを付けたもので
す。メモリも専用の FTP サーバには重要で、巨大なサーバでは 256 MB は欲
しいところです。もう少し小さなサーバなら 64 MB の RAM でも充分仕事をし
てくれるでしょう。しかしネットワーク接続の問題がいずれにしても最重要で
しょう。
10.2.3. WWW
WWW は多くの人々にとってインターネットを利用するきっかけとなりました。
また、この 2 つを同じものとみなしている人もこの「多くの人々」の中には
いるようですね。やはりネットワークによる影響が大ですが、ドライブの動作
も (特に Web ページのキャッシュに関して) 影響します。キャッシュ領域は
独立した速いドライブに置いておくと有利です。キャッシュ機能込みのプロキ
シサーバをインストールするとさらに良いでしょう。このようにすれば、それ
ぞれのユーザの WWW 要求をまとめられるので、キャッシュ領域のサイズも小
さくできますし、ネットワークのバンド幅も節約できます。
キャッシュ付きのプロキシサーバには高速なドライブ (アレイ) が必要になり
ます。 RAID 0 を利用できれば理想的です (信頼性はさほど必要ありませんか
ら)。大きな方が良いですが、 2 GB もあれば大抵は大丈夫でしょう。キャッ
シュを保持する期間を長くするとたくさんの領域が必要になりますが、キャッ
シュへのヒット率も向上します。しかしあまり長くしすぎるのも良くありませ
ん。できれば URL ごとに調整できると良いですね。さらに情報を求める人
は、サーバのドキュメントなどを調べてください。 Harvest や Squid
などが有名です。 Netscape
から出ているものもあるようです。
10.2.4. メール
メールはほとんどすべてのホストで扱われています。しかし大きなメールサー
バはメール配信機能に特化している場合が多いです。メール配送は負荷の大き
なタスクであり、大きなサーバではドライブとネット両方が高速でもなお速度
が遅い、ということもよくあります。 Linux の世界では vger.rutgers.edu
にある大きなサーバがよく知られている例です。ニュースサーバでは情報が分
散しているため、他のマシンからフィードすることによってスプールを再構成
できるのに対して、メールサーバは他とデータを共有しません。したがって安
全性が非常に重要となります。大きなサーバを運用している場合は、信頼性を
高めるために RAID の導入を考えるべきでしょう。容量は運用しているメーリ
ングリストの数と購読している読者によって大きく変わります。
巨大なメールサーバでは、 IO が性能のボトルネックになってしまうことがあ
ります。このため、巨大なシリコンディスクを SCSI につないで、そこにメー
ル関係のファイルを、一時ファイルも含めて置いている人もいるようです。安
全性を追求するため、これらにはバッテリーバックアップが用いられており、
また udf のようなファイルシステムが好まれています。このファイルシステ
ムは常にメタデータをディスクにフラッシュするからです。これは性能を落と
しますが、非常に高速なディスクを用いることで補償されています。
最近では、メールサーバから POP を使ってローカルマシンにメールを移動し
て来るやり方に代わって、メールアーカイブを一ヶ所に集中させておき、
IMAP で閲覧する手法が取られるようになってきています。これはすなわち、
メールはもはや「スプール」されるのではなく、ひたすら大きくなりつづける
ことを意味します。したがって膨大なディスク領域が必要になります。さら
に、ありとあらゆる通信に添付ファイルが頻用 (濫用) されるようになりまし
た。小さなワープロ文書ですら 1 MB を越えることが珍しくありません。ディ
スクは気前良く用意し、残りの容量に目を光らせましょう。
10.2.5. ニュース
ニュースは必要な領域が大きいですが、どの程度になるかは購読している
ニュースグループに大きく依存します。 nyx ではほとんどすべてのグループ
を購読しており、 17 GB 程度を消費しています。もっとも大きくなるのは明
らかに alt.binary.* 以下のグループです。もしこのグループを購読しなけれ
ば 12 GB 程度で良いサービスを提供できます。小規模なところには 2 GB 程
度で「サービスプロバイダ」と称しているところもあるようですが、この程度
では expire が非常に早くなってしまうでしょう。こういうところは「サービ
ス」の名に値しないと言うのが筆者の意見です。ニュースのフルフィードは毎
日数 GB のトラフィックを意味します。またこの値は大きくなり続けていま
す。
10.2.6. その他
ネットで利用できるサービスは非常に多くの種類がありますが、その多くは
WWW の影に隠れています。しかし archie や gopher, wais と言ったサービス
はまだまだ現役かつ有益なツールです。もし手元で大きなサーバを立ち上げる
つもりでしたら、これらのサービスについても考えるべきでしょう。必要な容
量を決定するのは難しく、人気と要求頻度に依存します。よいサービスを提供
するには当然コストが必要で、ディスク容量はその一つに過ぎません。
10.2.7. サーバ向けのお勧め
こんにち商用サーバに満足いく機能を発揮させるためには、大容量のディスク
を多数用いる必要があります。用いる要素部品が増えるほど平均故障時間
(mean time between failure: MTBF) は急激に短くなりますから、データを守
るために RAID を用いることを考えるべきだと思います。また巨大な一台の
ディスクの代わりに、やや小さい容量のドライブを複数用いることも考慮の価
値があります。より詳しい情報は High Availability (HA) プロジェクトを見
てみましょう。
High Availability HOWTO や、関連 web ページ
に、詳しい情報があります。
Byte にも How Big Does Your Unix Server Have To Be?
という記事があります。 Linux に関連する点も多いです。
10.3. 落とし穴
可能なものすべてを別々のパーティションに分けてしまうことに伴う危険性に
ついては、ボリューム管理の節において簡単に紹介しました。しかしこの点は
より強調しておくべきだというアドバイスが多かったので、もう一度言いま
す: 一度設定したパーティションは使い切ったらそれで終わりで、増やすこと
はできません。他のパーティションがいくら余っていてもです。
特にニューススプール (/var/spool/news) は爆発的に増えることがあるので
注意が必要です。 quota を利用したマルチユーザのマシンでは、 /tmp や
/var/tmp にも目を配り、ここにファイルを隠すユーザがいないかどうかも気
をつけましょう (特に .gif や .jpeg で終わる名前のファイルなど :-)。
実際のところドライブがひとつしかないようなシステムではパーティション分
割はあまり役に立ちません。メリットは df を使ってファイルサイズのモニタ
が簡単にできること、物理的なセクタ配置を行えることくらいでしょうか。致
命的なのはディスクの並列利用ができないことです。フリーで使えるようなボ
リューム管理システムが出てくればこの節の最初で述べた問題は解決します
が、これはもう少し先のことになりそうです。いろいろな機能に特化したファ
イルシステムが出てくれば、 1 ドライブのシステムにおいてもパーティショ
ン分割は有効になるでしょう。
より詳しい情報は ``トラブルシュート'' の章を見てください。
11. ディスクのレイアウト
さてさて、これまで述べてきたような知識をもとにして、いよいよ実際のレイ
アウトについて述べることにしましょう。以下の方法は筆者が 3 台の古
いSCSI ディスクを使って、いろいろな可能性を試しながら作り出してきたも
のです。
付録の表は、このマッピングの過程を簡単にするためにデザインされました。
最適化のプロセスをすすめていく作業の助けになるでしょうし、システムを改
善する時にも有用な記録となってくれるでしょう。いくつかの例も同時に載せ
てあります。
11.1. パーティションの選択
必要な機能を決め、別々のパーティションに分けるファイルシステムのリスト
を作ります。それを必要とされる速度の順に並べ、それぞれのパーティション
に割り当てる容量を決めます。
``付録 A'' の表が役に立つでしょう。この表には論理ディレクトリが順に並
べてあり、マウントポイントに関するメモや別の OS に使う領域を書き込む部
分が確保してあります。この表は速度順には並んでいません。代わりに必要と
される速度を 'o' の数で示してあります。
RAID を利用するのでしたら、どのディスクを使って、どのパーティションを
RAID 化するかを決めておきましょう。 RAID には色々な種類があり、様々な
速度／信頼性が選択できることを頭に入れておきましょう。
(以下では話を簡単にするために、同じ SCSI ディスクがいくつかある場合を
考えましょう。 RAID は使わないものとします)
11.2. パーティションとドライブのマッピング
次の段階では、パーティションをディスクに割り当てていきます。これから述
べるアルゴリズムのポイントは、並列性を最大限確保してバスの容量をめいっ
ぱい使うようにすることです。例として、ドライブ A B C に対してパーティ
ション 987654321 を割り当てることを考えます。 9 が最も高速性が要求され
るパーティションです。一つめのドライブから出発して、パーティションのラ
インを「くねらせて」いきます。こんな感じです。
A : 9 4 3
B : 8 5 2
C : 7 6 1
これで高速性の要求量に対する重みが、どのドライブでも同じくらいになりま
す。
``付録 B'' につけた表を使って、どのドライブのどのパーティションを用い
るかを選んでください。並列性が最高になるようにしましょう。
持っているドライブの速度の特性と、それぞれのディレクトリを適当な列に記
入してください。ディレクトリやパーティション、ドライブは何回か入れ替え
たくなるでしょうから、表はその分用意しておきましょう。
11.3. ドライブ上でパーティションを並べ替える
以上ができたら、それぞれのドライブでパーティションの番号づけを行いま
しょう。
``付録 C'' の表を用いて、パーティションの順番を決めてください。トラッ
クの特性が生かされるようにしましょう。全部できたら、表をパーティション
番号の昇順に並べ替えましょう。これらの番号を付録 A や B の表に書き戻し
てください。
fdisk や cfdisk などのパーティション分割プログラムを使うときやインス
トール作業を行うときに、これらの表を参考にすると良いでしょう。
11.4. 最適化
上の手続きの後、通常いくつかのパーティションは入れ替える必要がありま
す。大きさを合わせたり、速度、信頼性、その他ファイルシステム特有の問題
などを解決するためです。しかしそれでもここで与えた方法はドライブとパー
ティションを最適に設定するための良い出発点になります (と筆者は信じてい
ます)。何が必要とされるかについてを色々と考えてきたわけですが、本当の
ところは実際にシステムを運用してみないと解らないでしょう。実際に運用を
始めたのち、パーティションの切り直しが必要とされるような時期がいつかは
やって来ると思っていたほうが良いでしょう。
例えば上で用いた 3 台のドライブのうち、一つが他に比べて非常に遅いよう
な場合には、最適な配置は以下のようになるでしょう。
A : 9 6 5
B : 8 7 4
C : 3 2 1
11.4.1. 特性による最適化
総合的なスピードが似たようなドライブでも、ファイルのサイズやアクセスの
頻度などによって相性の良い悪いがあるものです。たとえばバイナリの置かれ
ているディレクトリはコマンドキューが機能するようなアクセスの速いドライ
ブに向いていますし、ライブラリのディレクトリには転送速度が大きいドライ
ブが良いでしょう。後者に対しては IDE ディスクのコストパフォーマンスが
高いかもしれません。
11.4.2. ドライブの並列化による最適化
タスクを実行するときに、ドライブ利用の競合が起こらないようにしましょ
う。たとえば /usr/local/bin にアクセスした直後に /usr/local/lib のファ
イルが必要になるような場合、これらのディレクトリを別々のドライブに置い
ておけば、シークや読み込み、キャッシュなどの並列化・高速化が期待できる
でしょう。並列動作が期待できる場合には、先に述べたような最適化がなされ
ている場合よりも優れた性能が得られることは充分ありえます。よく行われる
タスクでどのパーティションが同時に使われるかを考え、それらを別々のディ
スクに置くようにしましょう。
いまの内容をもう少し詳しく述べましょう。以下にタスク状況の解析例をいく
つか示します。
Office ソフト
エディタやワードプロセッサ、スプレッドシートなどが典型的な例で
す。 CPU の負荷もディスクの負荷もそれほど高くありません。しか
し、大量のユーザを抱えているサーバなどを管理している場合には、こ
れらのソフトのオートセーブ機能についてしっかり認識しておきましょ
う。この機能はホームディレクトリに余分なトラフィックを生じること
になります。ユーザのホームディレクトリをいくつかのドライブに分散
させておけば負荷の集中を減らすことができます。
ニュース
ニュースリーダもホームディレクトリへのオートセーブを行なうので、
サービスプロバイダならばホームディレクトリを別のドライブに分ける
方が良いでしょう。
ニューススプールはディレクトリ構造がとても深くなり、小さなファイ
ルがとてもたくさん置かれます。ニューススプールパーティションが失
われても大部分の人には大きな問題ではないでしょうから、小さなディ
スクをたくさん集めて RAID 0 の構成にし、シーク動作をたくさんのス
ピンドルに分散させると良いかもしれません。また INN ニュースサー
バのマニュアルや FAQ で推奨されていることですが、大きなニュース
サイトではニューススプールと .overview ファイルを別のドライブに
置いておくのが良いそうです。
INN optimising under Tru64 UNIX
にある記
述も、Linux ユーザを含む多くの読者に当てはまるでしょう。
データベース
データベースアプリケーションはドライブの容量と速度を両方とも必要
とします。詳細はもちろんアプリケーションによります。ドキュメント
を読むときにディスクの必要量に注意しておきましょう。性能や信頼性
を高めるためには RAID を導入するのも良いでしょう。
電子メール
メールの送受信にはホームディレクトリと到着用／発信用のスプールが
使われることになります。可能ならばホームディレクトリとスプールは
別のドライブに分けておくべきでしょう。メールサーバ (メールハブ)
では、到着用と発信用のスプールも別のドライブに分けると良いかもし
れません。
もしあなたが ISP やメジャーなメールハブマシンを管理しているとし
たら、メールを失うのはもう最悪です。メールスプールを RAID 化する
こと、頻繁にバックアップを取ることを考えましょう。
プログラム開発
たくさんのディレクトリが必要になります。コンパイラのバイナリやラ
イブラリ、インクルードファイル、さらにはソースやプロジェクトファ
イルなどなど。許す限り別々のドライブに分けておきましょう。小さな
システムでは /usr/src とプロジェクトファイルをホームディレクトリ
と一緒のドライブに入れてしまっても良いかもしれません。
Web ブラウザ
WWW は人気が増す一方ですね。多くのブラウザではローカルなキャッ
シュを用いており、これらはかなりの大きさになることがあります。
ローカルキャッシュは以前に読んだことのあるページを再ロードした
り、直前のページに戻ったりするときに用いられますので、この領域の
速度はとても重要です。しかしちゃんと設定されたプロキシサーバを経
由している場合なら、各ユーザ、各セッションにつき数 MB 程度あれば
充分でしょう。 ``ホームディレクトリ'' や ``WWW'' の節も参考にし
てください。
11.5. 妥協的手法
先に述べた ``落とし穴'' を避ける方法としては以下のようなものがありま
す。スワップや /tmp, /var/tmp のように比較的サイズが分かっているような
ディレクトリにだけそれぞれパーティションをあてがい、他のものは残った
パーティションにシンボリックリンクを使って割り振る方法です。
例を示しましょう。遅いディスクと速いディスクがあり、この中に一揃いのシ
ステムを詰め込むことを考えます。スワップと /tmp は速いディスクに置き、
/home と /root は遅いディスクへ置きます。この作業の後に残ったディレク
トリを仮に /a/slow, /a/fast, /b/slow, /b/fast としましょう。そして各ド
ライブの残ったパーティションに対してこれらのディレクトリを割り振ること
を考えます。
/a と /b をそれぞれのドライブにあてがってしまうと、サブディレクトリに
同じ性能が与えられてしまいます。 4 つのディレクトリをそれぞれ別のパー
ティションに分けると、今度は容量に対する柔軟性が失われてしてしまいま
す。
より良い解法はこれら 4 つのディレクトリをそれぞれに適したドライブの
ディレクトリに対するシンボリックリンクとすることです。
具体的には以下のようにします。ここで /mnt.fastdisk に速いディスクの残
りパーティションを、 /mnt.slowdisk に遅いデスクの残りパーティションを
マウントしているものと考えてください。
/a/fast は /mnt.fastdisk/a/fast または /mnt.fastdisk/a.fast へリンク
/a/slow は /mnt.slowdisk/a/slow または /mnt.slowdisk/a.slow へリンク
/b/fast は /mnt.fastdisk/b/fast または /mnt.fastdisk/b.fast へリンク
/b/slow は /mnt.slowdisk/b/slow または /mnt.slowdisk/b.slow へリンク
こうすればスピードが必要なディレクトリは速いディレクトリへおくことがで
き、しかもパーティションを 4 つに分割する必要もなくなります。リンク先
として右側のような表現を利用すればファイルシステムの無駄な階層化を防ぐ
ことができ、ディレクトリ構造が見やすくなるでしょう。
この方法の欠点はごちゃごちゃしすぎているため、初期段階での計画やセット
アップには向かないことです。またシステムのインストール前にすべてのマウ
ントポイントとパーティションを決めておかなければならないことも問題かも
しれません。
重要: /usr パーティションは直接 root にマウントすべきで、上記のような
間接リンクにすべきではありません。なぜなら、ずうっと根元に戻るようなリ
ンクが、 /usr の、特に X11 で頻繁に用いられており、これらは /usr 以下
から root に戻って、 /etc ディレクトリに戻ったりするからです。
12. パーティション分割の実作業
設計が終わった方のために、ここでは実際にパーティション分割を行うための
詳細な手順について示します。ここにあるのはガイダンスだけですが、実際に
行う作業を自動的に行ってくれるツールを誰かが作ってくれると素晴らしいで
すね。具体的には、設計、パーティション分割、フォーマット、インストール
ということになるでしょう。
最近の配布パッケージのインストーラには、パーティション分割からフォー
マット、 /etc/fstab の設定にいたるまでを自動的に行ってくれる機能がつい
ている場合が多いようです。しかし後に変更したくなったときのためには、背
後で行われている実際の作業の仕組みについて知っておく必要があるでしょ
う。
12.1. チェックリスト
はじめるに当たって必要なのは…
o どれをどこに置くかのメモ (自分なりの設計)
o ちゃんと動作する、テスト済みのレスキューディスク。
o 大事なデータの最新版バックアップ。
o フォーマットとテストをすませた空のフロッピーを最低 2 枚。
o fdisk（ないし同様のコマンド）の man ページを読んで理解しておくこ
と。
o 根気と集中力と馬力。
12.2. ドライブとパーティション
DOS などでは、起動するとすべてのパーティションが表示され、それぞれに
C: 以降のドライブ文字が割り当てられます。これは IDE、 SCSI、ネットワー
クドライブその他、どんなメディアでも同じように扱われます。ところが
Linux の世界では少々異なります。ブート時には以下のようなパーティション
の表示が出るはずです。
______________________________________________________________________
Dec 6 23:45:18 demos kernel: Partition check:
Dec 6 23:45:18 demos kernel: sda: sda1
Dec 6 23:45:18 demos kernel: hda: hda1 hda2
______________________________________________________________________
SCSI のドライブには sda, sdb, sdc のような、また (E)IDE のドライブには
hda, hdb, hdc のような名前が付きます。すべてのデバイスには、同様に標準
的な名前があります。詳細が知りたければ /dev/MAKEDEV と
/usr/src/linux/Documentation/devices.tex を見てください。
パーティションはそれぞれのドライブ名に数字が付加されたものです。つまり
hda1, hda2 のようになります。 SCSI ドライブではドライブ一台あたり 15
パーティションまで、 EIDE ドライブでは 63 パーティションまでです。両者
とも現在のところは、ほとんどのディスクに対して充分でしょう。
これらは /etc/fstab というファイルに書いてある情報に従ってマウントさ
れ、ファイルシステムの一部となります。
12.3. パーティション分割
It feels so good / It's a marginal risk / when I clear off / windows
with fdisk! (Dustbunny の User Friendly
中の漫画
に
おける歌 "Refund this" より。)
まず最初にそれぞれのドライブをパーティションに分割する必要があります。
Linux では主として二つの選択肢があります。 fdisk と、これをもう少しス
クリーン指向にした cfdisk です。これらは複雑なプログラムですので、マ
ニュアルをしっかり読んでおくようにしてください。熟練者なら、今では
sfdisk を用いることもできます。
パーティションには三つの種類があります。基本 (primary) パーティショ
ン、拡張 (extended) パーティション、そして論理 (logical) パーティショ
ンです。 Linux 以外の OS をブートさせるパーティションは基本パーティ
ションでなければなりませんが、これはドライブあたり 4 つまでしか用いる
ことができません。これ以上のパーティションを用いたい場合は拡張パーティ
ションを指定し、その中に複数の論理パーティションを作成します。
各々のパーティションには、対応する OS に応じた id 番号がふられていま
す。 Linux の場合は swap(82) と ext2fs(83) を使います。 RAID を
autostart で使いたい場合に、 RAID パーティションに用いるべきタイプ番号
については、ドキュメントをチェックしておく必要があります。
fdisk に付属の readme ファイルには、パーティション分割に関するより詳細
な情報が記載されています。
最近 Partitioning HOWTO という文書が出たようです。これにはパーティショ
ン分割のあれこれに関する詳細な情報が非常に良くまとめられています。その
内容をここに繰り返してこの文書をさらに巨大化させるのは止めておきます。
Partitioning HOWTO を読んでいただくことをおすすめします。
訳注: Partition HOWTO の日本語訳
は JF にあります。
Redhat は Disk Druid というスクリーン指向のユーティリティを作成しまし
た。これは fdisk や cfdisk と同じ動作をするユーザーフレンドリなプログ
ラムで、いくつかの作業を自動化もしてくれます。残念ながらこの製品はまだ
あまり枯れていないので、うまく動かないことがあるかもしれません。その場
合は fdisk か cfdisk を使ってください。
さらに Mandrakesoft も負けじと、よりグラフィカルなツール Diskdrake
を開発しました。こちらも、
とてもたくさんの機能を持っています。
GNU project も GNU Parted という
パーティション分割ツールを提供しています。
Ranish Partition Manager
というフリーのソフトウェアや、商用で良く使われているものでは Partition
Magic などもあります。後者では ext2fs パー
ティションのサイズ変更もある程度サポートしています。
Windows は一つのドライブに二つ以上の基本パーティションがあると文句を
行ってきます。また Windows でのドライブレターの割り当てでは、まず基本
パーティションをすべてのドライブから探し、その後で論理パーティションを
それぞれのディスクで再走査するようです。
DOS/Windows をシステムに共存させたい場合には、まず最初に DOS の fdisk
プログラムを使ってそれらをブートさせる基本パーティションを作成する必要
があります。さらに NT が必要なら、この段階で配置します。最後に Linux
のためのパーティションを Linux の fdisk プログラム群を用いて作成しま
す。 Linux は柔軟ですので、基本パーティションからでも論理パーティショ
ンからでもブートできます。
DOS の fdisk に関する非常に詳しい情報が Fdisk.com
と MS-DOS 5.00 - 7.10 Undocumented,
Secret + Hidden Features
から入手できます。バグや落とし穴に関しても詳しいです。
12.4. 再パーティション
時には既存のパーティションのサイズを、内部のデータを保ったままで変更し
なければならないかもしれません。もちろん一つの方法としては、すべてを
バックアップしてパーティションを作り直し、元の中身をレストアすれば良い
のです。これはバックアップシステムの良いテストにもなりますが、しかし時
間もかかります。
もう少し楽な別法として、パーティションをリサイズ (resizing) する方法も
あります。ここではまずどれかのファイルシステムを望む容量に縮めて、それ
からそのパーティションの末尾にあわせてパーティションテーブルを書き換え
ます。したがってこの手法はファイルシステムに依存します。
パーティションをしなおすには、サイズを縮めるためにファイルシステムの末
尾に空きスペースが必要です。まずデフラグメントを行って、ドライブに空白
の隙間がないようにしてください。
fips を用いれば fat パーティ
ションをリサイズできます。 fips の最新版である 1.6 版や fips 2.0 を使
えば、 fat32 のパーティションもリサイズできます。これらのプログラムは
DOS の下で動作します。
その他のファイルシステムのリサイズはずっと難しいのですが、有名な商用ソ
フトウェアの Partition Magic では、
resize2fs を用いて ext2fs を含むより多くのファイルシステムをリサイズで
きます。最近、大きなディスクに対して問題が生じる版があったので、最新版
を入手するようにしてください。
fips の効果を最大にするには、ドライブのデフラグメントを行う前にまず不
必要なファイルや空き領域を削除する必要があります。こうすれば他のパー
ティションにより多くの空間を割り当てられます。プログラムが「ドライブの
末尾にファイルがある」と文句を言ってきた場合、それは Microsoft Mirror
か Norton Image によって作成された隠し属性のファイルである可能性が高い
です。それらには image.idx や image.dat という名前がついており、いくつ
かのシステムファイルのバックアップ情報を保持しています。
いくつかの報告によれば、 Windows のデフラグメントツールによっては、
"Windows にファイルの再配置を許可する (allow Windows to move files
around)" というボックスをチェックしないようにする必要があるのだそうで
す。そうしないといくつかのファイルが末尾のシリンダに配置されてしまうの
で、 FIPS はその空間を再利用できなくなってしまいます。
どうしても DOS パーティションの末尾に動かせないファイルが残ってしまう
場合は、 DOS プログラム showfat
の 3.0 版以降を入
手しましょう。このプログラムはそこにあるファイルを表示してくれますの
で、直接扱うことが可能になります。
同じ機能を持ったフリーウェア版としては Partition Resizer
があります。パーティションの縮小・拡
大・移動ができます。
DOS / Windows の版によっては、 defrag に隠しオプション /P があり、これ
を指定すると defrag は hidden ファイルも移動するようになります。 at
your own risk でどうぞ。
パーティションの切り直しはとても危険な作業ですから、最新のバックアップ
を手元に置いておくようにしましょう。
12.5. Microsoft パーティションのバグ
Windows 98 に至るまでのすべての Microsoft 製品にはちょっと面倒なバグが
あって、これが少々問題になる人もいるかもしれません。 fat パーティショ
ンを複数使っているとき、拡張パーティションの末尾が fat パーティション
でないと、 Microsoft のシステムは「基本パーティションの末尾にある FAT
パーティション」の代わりに「末尾の拡張パーティション」を FAT パーティ
ションとしてマウントしようとしてしまうのです。
この問題に関する詳細な情報 は、ネットワークか
ら入手できます。
これを避けるには、小さな論理 fat パーティションをディスクの一番最後に
配置すれば OK です。
マルチ OS のインストールに関する詳しい情報は V Communications
からも入手できます。しかし彼らはリンクをいじり
続けているので、ここでは直接のリンクを掲載できません。
ハードウェアの設定ソフトには DOS でしか動かないものもありますから、こ
のパーティションは多少は役にたつでしょう。たとえば DPT の RAID コント
ローラや多くのネットワークカードなどがそうですね。
12.6. 複数デバイスの一括利用 (md: Multiple Devices)
これはカーネルに付属の機能です。まだ開発は続いていますので、最新のド
キュメントを良く読んでおくようにしてください。不安定かも知れませんの
で、注意してください。
簡単に説明しますと、この機能は複数のデバイスをまとめて、 md0 (あるいは
md1) という新しいデバイスを作ります。この際には mdadd というプログラム
が用いられ、 mdrun によって利用できるようになります。この作業は
/etc/mdtab というファイルによって自動化が可能です。
最新版の md システムでは /etc/raidtab を用い、これは別の書式で書きま
す。使っている RAID-tools のパッケージが md のバージョンとマッチしてい
るか確認してください。内部で用いているプロトコルが変更されていますの
で。
mdrun 以降には、このデバイスは他のドライブパーティションと全く同じよう
に使うことができます。以下の記述に従って、フォーマット等の作業を行なっ
てください。
md を用いた RAID に関する HOWTO も成長中です。読んでおきましょう。
12.7. フォーマット
次に行なうのはパーティションのフォーマットです。この作業は、ディスク表
面にデータ構造を書き込み、ファイルの書き込み位置を指定できるようにする
ものです。一番最初にフォーマットを行なう場合は、同時にベリファイを行な
うように指定すると良いでしょう。この作業は本来の目的には必要ないのです
が、ディスク I/Oのテストとして有効です。ディスク入出力が連続して頻繁に
行われるので、潜在的な問題 (ターミネーションの不正など) を発見できる可
能性があります。ベリファイ機能の詳細に関しては mkfs のマニュアルを見て
ください。
Linux は非常に多くのファイルシステムをサポートしています。ここでそのす
べてを挙げることもできますが、 man fs してもらう方が良いでしょう。ここ
には各々のファイルシステムに関する情報も多少書かれています。なおこれら
のファイルシステムを用いるには、それに応じたドライバをカーネルに組み込
む (あるいはモジュールとして用意する) 必要があります。カーネルをコンパ
イルする際に、ファイルシステム機能のリストを注意して読むようにしてくだ
さい。 make menuconfig を用いれば、それぞれのファイルシステムに関する
オンラインヘルプを見ることもできます。
レスキューディスク作成パッケージには、 minix, msdos, ext2fs のサポート
をカーネルに組み込んでいないと使えないものがあるようです。
スワップデバイスにおいても、フォーマットに準ずる作業を行なう必要があり
ます。これには mkswap を用います。
DOS や Windows でのフォーマットに関する重要な内容が MS-DOS 5.00 - 7.10
Undocumented, Secret + Hidden Features
にあります。
ここでの「フォーマット」は高レベルのフォーマットのことであり、ファイル
システムをディスクに作成するものです。これに対して低レベルのフォーマッ
トは、トラックとセクタをディスクに配置します。後者は今日ではほとんど必
要ありません。
12.8. マウント
パーティション上にデータを読み書きするには、まず適切なマウントポイント
にそのパーティションをマウントしなければなりません。これを手動で行なう
には mount コマンドを用います。またブート時に自動的に行なうには、必要
な情報を /etc/fstab ファイルに追加します。後者を行なう際には mount の
man ページをよく読んでください。記述を間違えた場合は、最悪システムが立
ち上がらなくなる場合があります。
12.9. fstab
ブート動作の途中で、システムは fstab ファイルの記述に従ってすべての
パーティションをマウントします。以下のような内容になっているでしょう。
______________________________________________________________________
#
/dev/hda2 / ext2 defaults 0 1
None none swap sw 0 0
proc /proc proc defaults 0 0
/dev/hda1 /dosc vfat defaults 0 1
______________________________________________________________________
このファイルは書式に厳しいので、専用の編集ツールを用いるほうが良いし、
また便利でしょう。例えば Tcl/Tk ベースのファイルシステムマウンターであ
る on the netfstool や、KDE
のエディットツール kfstab などがあ
ります。
それぞれのフィールドを順に簡単に紹介すると、パーティションの名前、マウ
ント先、ファイルシステムのタイプ、マウントのオプション、いつ dump して
バックアップをとるか、そしていつ fsck するか、です。
Linux ではファイルチェック (fsck) を並列動作させることも可能です。しか
し効率のためには、一つのドライブ上にある複数のファイルシステムは同時に
fsck させないことが大事です。
12.10. マウントオプション
(手動にしろ fstab 経由にしろ) マウントの際にはたくさんのオプションが利
用でき、様々な保護が可能になっています。以下では中でも便利なオプション
を紹介します。
nodev
このファイルシステム上のキャラクタスペシャルデバイスやブロックス
ペシャルデバイスを利用禁止にする。
noexec
マウントされたファイルシステム上のバイナリを実行禁止にする。ス
プール領域に便利。
nosuid
マウントされたファイルシステム上での SUID, SGID を禁止する。ホー
ムディレクトリに便利。
より詳しい情報や注意点については mount や fstab のマニュアルページを見
てください。
12.11. お勧め
設定と実装を賢く行うことができたら、すべてを「紙に」記録しておきましょ
う。ディスク上の情報は、マシンがダウンしたら全く使えませんからね。
パーティションテーブルは破壊されたり失われたりすることもあります。その
場合には、 fdisk の正確な数値の記録がものすごく価値を持つことになりま
す。その値を入力すればシステムを救えるのですから。 printpar プログラム
を用いて、テーブルをわかりやすい形に記録しておくこともできます。またそ
れぞれのディスクの SCSI 番号や IDE 名も書いておきましょう。そうしない
とシステムを正しい順序で再構成できません。
``付録 M:'' にも、現在のディスクの設定のサマリを生成する小さなスクリプ
トを置いておきました。
ハードディスクのチェックには、ネットから入手できる Disk Advisor boot
disk が利用できます。 disk builder を実行す
るには Windows が必要でした。このシステムはおかしくなったディスクの診
断に有用です。
なお、レスキューディスクは是非作成してテストしておきましょう。ほとんど
のディストリビューションで (おそらくインストールディスクの一部として)
提供されています。 RedHat 6.1 などの一部のディストリビューションでは、
ディスクをレスキュー用途で起動するには、ブートプロンプトで linux
rescue とタイプすることになっています。
レスキュー用途に特化したディスクもネットで配布されています。
これらが必要になったときは、システムの root と boot パーティションがど
こにあり、どこに書いてよいか・いけないかを把握している必要があります。
メモ: ブートディスクとレスキューディスクの違いは、前者はファイルシステ
ムを (通常はハードディスク上のものを) マウントできない場合、起動に失敗
するという点にあります。レスキューディスクはそれ自体のシステムを含んで
おり、ハードディスクがなくても動作します。
13. メンテナンス
ドライブとパーティションを監視し続けることはシステム管理者の義務である
と言えます。どこかのパーティションが一杯になってしまえば、パーティショ
ン容量の再配置がすむまでシステムは正しく働かなくなってしまうのですか
ら。
パーティションとディスクの監視は df コマンドによって簡単に行えます。頻
繁に行うべきですし、 cron や他の管理ツールなどを使って定期的に行うよう
にするのも良いでしょう。
スワップパーティションも忘れないようにしましょう。 free や procinfo,
top といったメモリ利用の統計表示ツールを用いることで監視できます。
ドライブの使用状況のモニタはもうちょっと難しいですが、ドライブ利用の競
合を避けてシステムの性能を上げるには重要な作業です。アクセス要求がひと
つのディスクに偏らないようにしましょう。
ソフトウェアのパッケージをインストールするとき、どこにどのファイルを配
置するかについて明確な意図を持つようにすることも重要です。先に紹介した
ように、 GCC は実行バイナリをライブラリのディレクトリに置きます。他に
も歴史的な経緯から、わけのわからない配置をするパッケージもあります。
X11 なんかがそうですね。
お使いのシステムのディスクが一杯になりかけたら、まず古いログを探して消
去しましょう。 core ファイルも探してみましょう。シェルのグローバルな設
定に ulimit を正しく用いておくと、 core でシステムをいっぱいにせずにす
みます。
13.1. バックアップ
これまでの部分をじっくりと読んできた方は、すでに何回かバックアップの重
要性に触れてきたことに気付いたでしょう。クラッシュに当たってバックアッ
プが機能していなかった、あるいは存在すらしなかった場合に管理者に降りか
かる災厄については恐ろしい話がたくさんあります。クラッシュが起こってか
らじたばたするよりは、普段からバックアップに投資しておく方がはるかに話
は簡単になるはずです。
バックアップには色々な手段が可能ですが、この辺りの詳細は Backup-with-
MSDOS-mini-HOWTO に記述があります。この文書には DOS に関する話だけでは
なく、一般的な情報や、より詳細な情報へのポインタも書いてあります。
訳注: Backup-With-MSDOS.html の日本語訳
は JF にあり
ます。同種の文書として dump and restore mini HOWTO
もおす
すめです。
ただバックアップをとるだけでなく、バックアップデータをちゃんと復元でき
るかどうかも確認しておきましょう。恐い話をひとつ。心掛けの良かった管理
者がクラッシュに遭遇。「ああ、普段からバックアップを取っていて本当に良
かった」バックアップデータの復元をはじめたら、何とそのデータが壊れてい
た... 気をつけましょうね。
Linux のバックアップソフトには、フリーなものも商用のものも存在します。
商用のものの例としては、ディスクイメージレベルでのバックアップシステム
を QuickStart が提供しています。すべての機能
を含む 30 日限定の Linux 用デモ版がオンラインで入手できます。
13.2. デフラグメント
これはファイルシステムの設計によって随分違います。早い段階からフラグメ
ンテーションが起きてしまい、しかもそれによって非常に速度が低下するよう
なシステムもあります。幸いなことに ext2fs はそうではないので、デフラグ
メントツールに関してもほとんど話題になることはありませんでした。実は
ちゃんと存在しているのですが、これまではほとんど必要なかったのです。
なんらかの理由でデフラグメント作業が必要になった場合は、バックアップと
レストアを行なってしまうのが簡単でしょう。例えばホームディレクトリのよ
うな小さな領域だけならば、その領域を tar で別のパーティションに一時待
避し、アーカイブを確認して、オリジナルを消してから再書き込みすれば良い
でしょう。
13.3. 不要ファイルの削除
ディスク領域の不足が、システムのあちこちに散らばっている不必要なファイ
ルを削除するだけで解消してしまうことも良くあるものです。異常終了したプ
ログラムは、さまざまなガラクタを、思いもよらないような場所に残してしま
うことが良くあります。このような事故があった場合には、通常はコアダンプ
が残されます。デバッグを行わないならば単に削除してかまいません。コアダ
ンプはどこにでも作成されますから、ときどきグローバルに検索を行うと良い
でしょう。これには locate コマンドが便利です。
正常に終了しなかったプログラムは、いろいろな種類の一時ファイルを残すこ
ともあります。これらは /tmp や /var/tmp に置かれ、通常ならプログラムの
終了時に自動的に削除されるはずのものです。このような領域は再起動を行え
ばきれいにされるはずですが、すべてがそうであるとは限りませんし、
uptime が長ければ大量のゴミが溜まることになってしまいます。領域が足り
なくなったら、注意しながら削除しましょう。そのファイルが現在使われてい
るものではないことを、まず確認してから削除するようにしましょう。 file
のようなユーティリティを用いれば、そのファイルが何であるかわかることも
多いです。
システムが動作している場合には、多くの記録が残されます。それらの多くは
/var/log ディレクトリに保存されます。特に /var/log/messages は、削除し
ないとどんどん大きくなります。古いログファイルからなる小さなアーカイブ
をいくつか用意しておくと良いと思います。それらを比較すれば、システムが
おかしくなりかかっていないかをチェックできますから。
メールまたはニュースのシステムが正しく動作していないと、スプール領域が
余計に消費されます。それぞれ /var/spool/mail と /var/spool/news です。
overview ファイルには注意すること。このファイルには先頭にドットがつい
ているので、 ls -l しただけでは見えません。 ls -Al を用いて、これらの
ファイルにも常に注意するように。
ユーザー領域のオーバーフローは特に難しい問題です。システム管理者とユー
ザの間には、ずっと闘争が行われ続けています。気転や交渉術が必要です。時
には実際に新たなドライブを購入してあげる必要もあるでしょう。 message-
of-the-day の機能 (ログインしたときに /etc/motd の内容が表示される) を
うまく使いましょう。ディスクが足りなくなった場合は、これでユーザーに知
らせるようにしましょう。また shell のデフォルトの設定で、コアダンプ
ファイルが作成されないようにしておけば、余計な仕事がかなり減ると思いま
す。
システムのあちこちに自分のファイルを隠そうとするような人たちもいます。
先頭にドットがつくファイルは ls コマンドでは見えませんので、この点が良
く利用されます。よくある例としては、 ... のようなファイル名です。通常
は見えませんし、 ls -al ではすべてのディレクトリに存在している . や ..
にまぎれてしまいます。これに対する対抗策としては、 ls -Al を使うことで
す。このオプションでは . と .. は見えませんが、その他のドットファイル
は見えるようになります。
13.4. システムのアップグレード
いかに大きなドライブと言えど、いずれは使いきってしまうときがやってきま
す。そのころには技術の進歩によるコストパフォーマンスの向上も期待できる
でしょう。現在のところは 6.4 GB クラスが一番良いでしょうか。
訳注: いまは 60GB くらいでしょうか？ :-)
たいていのマザーボードでは IDE は二つ (あるいは四つ) までしか接続でき
ないので、 IDE ドライブを増設する場合には古いものが無駄になってしまう
可能性が高いです。一方 SCSI は narrow (8 bit) SCSI で 7、 wide (15
bit) SCSI で 15 まで接続できます。またホストアダプタによっては二つ以上
のチャンネルをサポートしているものもありますし、場合によっては二つ以上
のホストアダプタを一つのシステムに使うこともできます。筆者の個人的なお
勧めですが、長期間に渡って利用するシステムには SCSI を選択しておく方が
良いでしょう。
ここで問題になるのは、どこに新しいドライブをあてがうかです。スプール領
域の不足が増設の理由になることが多いので、この場合は /var/spool 以下の
どこかに新しいディスクをマウントしてしまえば良いでしょう。しかし一方、
新しいディスクは高速でもあるでしょうから、長い目で見た場合はシステム全
体を再構成する方が良いかもしれません。その場合は以前に使った設計書が役
に立つでしょう。
システムのアップグレードが必要になった原因が /usr や /var などのパー
ティションの容量の枯渇である場合には、アップグレードの作業はやや面倒に
なります。全体を好みの配布パッケージで (おそらくこちらもアップグレード
されてるでしょうから) 再インストールすることをまず考えてみると良いで
しょう。この場合には、現在の重要な設定を上書きしないように気をつける必
要があります。これらの多くは /etc ディレクトリにあるでしょう。気を付け
て作業を進め、最新のバックアップとレスキューディスクを用意しておくよう
にしましょう。もう一つの選択肢もあります。新しいディレクトリを一時的な
ポイントにマウントして、古いディレクトリの内容を単純にコピーします。次
に /etc/fstab を編集して新しい方を有効にし、リブートしてちゃんと動いて
いるかどうかをチェックします。うまく行かなければレスキューディスクでリ
ブートして /etc/fstab を再編集し、もう一度トライしましょう。
ボリューム管理が Linux で使えるようになるまでは、これらの手段はいずれ
も面倒ですし危険でもあります。システムをバックアップからレストアするは
めになることを覚悟しておくことです。
Tips-HOWTO ではディレクトリ構造を丸ごとコピーする方法として、以下の例
を挙げています:
______________________________________________________________________
(cd /source/directory; tar cf - . ) | (cd /dest/directory; tar xvfp -)
______________________________________________________________________
この手法によるディレクトリ移動は、すべての Unix システムで利用できます
が、覚えておくにはちょっと不便です。またツリーが深くなって、パス名が
tar の扱える長さを越えてしまうと、この作業は失敗してしまいます (GNU
tar では長いパス名も使えるように特別な拡張が施してあります)。
GNU の cp を使えるなら (Linux システムなら使えるはず)、以下でも同じこ
とができます。
______________________________________________________________________
cp -av /source/directory /dest/directory
______________________________________________________________________
GNU cp はシンボリックリンク、ハードリンク、FIFO、デバイスファイルなど
についてそれぞれ知識を持っていて、正しくコピーを行えます。
ただし /dev や /proc を移動しようとするのはあまり良い考えではないこと
も覚えておいてください。
Hard Disk Upgrade mini-HOWTO という文書もあり、 LILO を含む Linux システム全体を別の
ディスクに移動する手順をステップバイステップで解説しています。
13.5. 復旧
システムのクラッシュは、さまざまな (楽しい) かたちでやってきます。特に
パーティションテーブルが破壊されると、たっぷりスリルを味わうことができ
ます。普通のスリルでかまわない人には、最近出た非常に便利なツール、
gpart があります。
「PC ハードディスクの形式を推定 (Guess PC-Type hard disk partitions)」
の acronym です。便利です。
さらに DOS で使えるパーティションユーティリティ
もいくつか存在しています。
13.6. レスキューディスク
カーネルやハードウェアのアップデートは、 Linux の世界では珍しいことで
はありません。したがって、最新のレスキューディスクを用意しておくことが
重要です。ハードウェアへのアクセスに特殊なドライバを使う場合にはなおさ
らです。レスキューディスクはネットやディストリビューションから入手でき
ますし、自分で作ることもできます。 boot および root のカーネルパラメー
タを確認し、カーネルがシステムをちゃんとブートできるようにしておくのを
忘れないように。
復旧フロッピーを持っていない人は、ブートローダである GRUB
を用いれば、ディスクのどこかにある
Linux カーネルを引き数を指定してロードできます。
14. 上級者向け情報
Linux のようなシステムでは、「高速かつ効果的ではあるが、致命的な破壊を
もたらす可能性がある」手法がたくさんあります。この文書も例外ではありま
せん。パワーには危険が付きものなのです。以下のセクションではいくつかの
奥義について触れています。これらは関連文書をしっかり読んで、危険性を熟
知した上で使うようにしてください。バックアップもとっておくべきでしょ
う。バックアップを使ってゼロからシステムを復元できるかどうかも一度は試
しておいてください。「バックアップはあるけど復元システムがない」と言う
ようなはめに陥った人は、過去に何人もいるのです (あるいはもっと恥ずかし
いことには、キーになるファイルがテープにない、とか)。
ここで述べているテクニックはほとんど必要とはされないでしょうが、ごく特
殊な設定では用いることもできます。実行する前に、ほんとうに自分がそれを
望んでいるかどうかを良く考えてください。
hdparm を用いたチューニングに関するより詳しい情報を求める方は The Need
For Speed
という記事を読んでみましょう。
14.1. ハードディスクのチューニング
ハードディスクのパラメータは hdparms ユーティリティでチューンする事が
できます。最も効果的であろうパラメータとしては read-ahead があります。
これはシーケンシャルな読み込みにおけるプリフェッチの量を指定するもので
す。
これを試してみる場合は、システムで良く使われているファイルサイズに合わ
せると、もっとも効果が高いでしょう。しかしこの設定はドライブ全体に用い
られるので、ちょっと難しいことになります。おそらくこの手法が有効なの
は、大きなサーバでドライブ全体がニュースに用いられている場合などに限ら
れるでしょう。
安全のため、デフォルトの hdparm の設定はやや保守的になっています。この
設定の欠点は、頻繁に IRQ が飛び交うような環境では割り込みをロストして
しまう可能性があることです。例えばシリアルポートと IDE ディスクを両方
使っているような場合、 IDE から発行された IRQ は他からの IRQ をマスク
してしまいます。するとネットからディスクにデータをダウンロードするとき
など、理想的な値から性能が (それとわかるくらいに) 落ちてしまうのです。
このマスク動作をやめるには hdparm -u1 device とします。性能が上がるか
もしれませんが、ハードウェアによっては逆にディスク上のデータが壊れてし
まうかもしれません。最新のバックアップを取ってから、注意して実験してく
ださい。
hdparm を用いたチューニングに関するより詳しい情報を求める方は The Need
For Speed
という記事を読んでみましょう。
14.2. ファイルシステムのチューニング
ほとんどのファイルシステムにはチューニングのためのユーティリティがあり
ます。 ext2fs には tune2fs があります。変更できるパラメータはいくつか
ありますが、最も便利なのは予約領域の大きさと、それを利用できるユーザを
設定するものでしょう。これによってドライブを余分に使えるようになりま
す。ただしクラッシュしたときに修理用の領域が少なくなるというデメリット
もあります。
14.3. スピンドルを同期させる
この方法そのものは危険ではありません。ただし特定の要素が絡むとまずいこ
ともあるようです。多くのドライブでは、このあたりの詳細ははっきりしてい
ません。理論は単純で、 RAID を組んでいるディスク間で位相の差を一定に
保っておけば、リクエストのあったトラックに読み書きを行うヘッドが到達す
るまでの時間を短くできるだろう、というものです。実際には、最近のドライ
ブには大きな先読みバッファがあるので、この効果は無視できるくらい小さく
なったようです。
スピンドルの同期は RAID 0 や RAID 0/1 では用いるべきではありません。な
ぜならミラーされたセクタの別々の領域に、それぞれの読み取りヘッドを配置
できるという利点が失われてしまうからです。
15. トラブルシュート
世の中はうまくいかないことが往々にしてあるものです。ということで、ここ
に症状・問題・解決法のリストを作っていきたいと思います。
15.1. インストール中
15.1.1. ディスクの配置
症状
ディスクが見つからない。
問題
どのドライブレターがどのディスク/パーティションに対応するのかわ
からない。
解決法
Linux はドライブレターの代わりにデバイス名を使います。詳細は ``
ドライブ名'' を見てください。
症状
ディスクをパーティション分割できない。
問題
ほとんどの場合は fdisk などのツールでの入力ミス。
解決法
単に hda と入力するのではなく、/dev/hda と入力します。また hda
の後には番号をつけないように。つけるとパーティションを指すことに
なります。
15.1.2. フォーマット
症状
ディスクをフォーマットできない。
問題
フォーマットできるのはディスクではなくパーティション。
解決法
フォーマットの対象をコマンドラインから指定する際、ディスクのデバ
イス名の後にパーティション番号をつけるようにしてください。
/dev/hda1 のようになります。
15.2. ブート中
15.2.1. ブートに失敗する
症状
数字が画面に表示され続ける。
問題
おそらくディスクに問題がある。
解決法
別のディスクを試してください。再インストールしなければならないか
も知れません。ケーブルが緩んでいないか、データが壊れていないかも
確認してください。
症状
LI が表示されてハングアップする。
問題
linux のロードに LILO が使われているが、 LILO が root を見つけら
れない。
解決法
LILO HOWTO を読んでください。
症状
カーネルが、 root ファイルシステムがないといって panic になる。
問題
カーネルが root パーティションの場所を知らない。
解決法
rdev や (可能なら) LILO を使って、カーネルイメージに root の場所
の情報を追加してください。
15.2.2. シングルユーザーモードになる。
症状
システムはブートするが、シングルユーザーモードで root のシェルが
起動する。
問題
ブートの終盤で何か問題が生じた。シェルを開いてシステムを修復可能
なところまでは来ている。
解決法
ブートのログから問題を見つけてください。ファイルシステムはリード
オンリーになっているかもしれませんので、必要な場合は読み書きモー
ドで再マウントしてください。 /etc/fstab に問題のあるエントリがあ
るような場合が多いようです (スワップパーティションを通常のファイ
ル空間にマウントしようとしているなど)。
15.3. 動作中
15.3.1. スワップ
症状
メモリが足りなくなった。
問題
スワップが有効になっていない。
解決法
free と入力して出力を調べてください。
total used free shared buffers cached
Mem: 46920 30136 16784 7480 11788 5764
-/+ buffers/cache: 12584 34336
Swap: 128484 9176 119308
のようになっていれば、システムは問題なく動作しています。 Swap: の行
が 0 になっている場合は、スワップ (パーティションまたはスワップファ
イル) をマウントしていない (swapon(8) を見よ)、スワップをフォーマッ
トしていない (mkswap(8) を見よ) などが考えられます。
15.3.2. パーティション
症状
No room amidst plenty 1
問題
オーバーパーティション症候群: パーティションサイズが小さすぎるど
こかの領域がオーバーフローを起こしている。
解決法
パーティションの利用状況を df(1) で調べ、問題のある領域を特定し
てください。問題のある部分を削除すれば解決することが多いですが、
システムを再パーティションしなければならないかもしれません。 ``
再パーティション'' の章を見てください。
症状
No room amidst plenty 2
問題
どこかの領域で i ノードが使い果たされてしまった。ニューススプー
ルのような、小さなファイルがたくさん置かれる領域であることが多
い。
解決法
パーティションの利用状況を df -i で調べ、問題のある領域を特定し
てください。通常は、 i ノードを増やしてその領域を再フォーマット
すれば解決します。 mkfs(8) や、関連する man ページを見てくださ
い。
16. この文書以外の情報
巨大なシステムをセットアップする場合などに見ておくべき情報は、他にもた
くさんあります。例えばニュース、一般のインターネットプロバイダなどで
す。以下のニュースグループにおける FAQ も役に立ちます。
16.1. ニュースグループ
特に面白いグループとしては、以下のようなものがあります。
o Storage .
o PC storage .
o AFS .
o SCSI .
o Linux setup .
ほとんどのニュースグループには対応する FAQ が存在し、その名の通り、ほ
とんどの質問に答えてくれるでしょう。最新のバージョンは定期的にその
ニュースグループにポストされるはずです。ニューススプールになかった場合
は FAQ main archive FTP site を見てみましょう。
WWW 版も FAQ main archive WWW site から見ることができます。
FAQ によっては独自のホームサイトが用意されているものもあります。この文
書に関連するものとしては以下を挙げておきます。
o SCSI FAQ
o comp.arch.storage FAQ .
16.2. メーリングリスト
これは主に開発者向けの、ノイズ発言の少ないチャンネルです。ここに質問を
する前には 2 回考えなおしてみること。ノイズは開発を遅らせてしまうから
です。関連したリストとしては linux-raid, linux-scsi, linux-ext2fs など
があります。このような非常に有用なメーリングリストが、
vger.rutgers.edu サーバにはたくさんあります。しかしここは非常に負荷が
高くなっているので、ミラーを探してみましょう。いくつかのリストが The
Redhat Home Page でミラーされています。多くの
リストは kernelnotes.org でもアクセスで
きます。この web サイトにある他のページも有用な情報の宝の山です。
利用できるリストについてもっと知りたい場合は、 lists という一行を書い
たメッセージを vger.rutgers.edu のリストサーバ
majordomo@vger.rutgers.edu に送ってください。メールサーバの使い方がわ
からない場合は、このアドレスに help とだけ書いて送ってください。この
サーバは人気が高いので、返事が来るまでには多少時間がかかるかもしれませ
ん。また subscribe コマンドを送ってからメールが配信されるまでにも、同
じように時間がかかるかもしれません。
majordomo のリストサーバには、他にも面白いものがあります。たとえば
EATA driver list (linux-eata@mail.uni-mainz.de) や Intelligent IO list
(linux-i2o@dpt.com) などが挙げられるでしょう。
メーリングリストというものは常に流動的ですが、多くの興味深いリストが
Linux Documentation Homepage からリンクされ
ています。
16.3. HOWTO
これらは、ユーザが背景知識を得るための出発点となることを意図して書かれ
ている文書です。特定の問題に関する解答を示すこともあります。関連する
HOWTO としては Bootdisk, Installation, SCSI, UMSDOS などがあります。こ
れらのメインサイトは、 LDP アーカイブ で
す。
DPT RAID システムの設定を扱う新しい HOWTO も公開されました。 DPT RAID
HOWTO homepage を
チェックしてみましょう。
16.4. Mini-HOWTO
HOWTO に比べ少々小さな文書で、テキスト形式で書かれていることも多いで
す。関連する mini-HOWTO 文書としては、 Backup-With-MSDOS, Diskless,
LILO, Large Disk Linux+DOS+Win95+OS2, Linux+OS2+DOS, Linux+Win95, NFS-
Root, Win95+Win+Linux, ZIP Drive などが挙げられます。これらは HOWTO と
同じところから入手できます。通常は mini というサブディレクトリに置かれ
ています。これらは近い将来には SGML に変換され、 mini のつかない HOWTO
になる予定です。
Linux Large IDE mini-HOWTO は古いので、もう正しくありません。代わりに
/usr/src/linux/drivers/block/README.ide または
/usr/src/linux/Documentation/ide.txt を読みましょう。
訳注: 以上の HOWTO, mini-HOWTO 文書のいくつかは、 JF プロジェクト
より日本語訳が入手できます。
16.5. ローカルな情報源
Linux のほとんどのディストリビューションには、すでに文書ディレクトリが
存在しているはずです。 /usr/doc を見てみましょう。ほとんどのパッケージ
が、主要な文書や README ファイルなどをこのディレクトリ以下に配置してい
ます。ここの /usr/doc/HOWTO には整形済みの HOWTO があるはずですし、
/usr/doc/HOWTO/mini にはプレインテキストの文書があるはずです。
これまでに紹介してきた設定ファイルの多くは /etc ディレクトリにありま
す。特に作業する必要がありそうなのは /etc/fstab ファイルでしょう。これ
はパーティションのマウント情報を扱います。また md を用いて RAID を設定
するには /etc/mdtab ファイルを使います (訳注: 最近の版のソフトウェア
RAID では /etc/raidtab)。
/usr/src/linux 以下のカーネルソースは、もちろん究極のドキュメントで
す。別の言い方をすれば「ルークよ、ソースを使え (use the source,
Luke)」です。カーネルのアーカイブには、ソースコード (とそれに付属する
少なくとも最低限のコメント) だけでなく、文書が置かれたディレクトリ
/usr/src/linux/Documentation が含まれていることも紹介しておきましょ
う。カーネルに関する質問をする前には、これらをまず読むことです。あなた
自身や、他の多くの人たちの時間を節約することになりますし、恥をかかずに
すむかもしれません。
システムのログファイル /var/log/messages も見ておきましょう。何が動作
しているか、特にブートがどのように行われているかがわかります (スクリー
ンはスクロールアウトしちゃいますからね)。別のウィンドウやスクリーンで
tail -f /var/log/messages すれば、システムに起こっていることを継続して
監視できます。
/proc ファイルシステムからも有用な情報が得られるでしょう。ここは動作し
ているシステム内部へののぞき窓なのです。ここにあるファイルを見るには
more ではなく cat を使いましょう。前者では、これらは大きさゼロのファイ
ルとして扱われてしまうからです。 less ならうまく見える、という報告もあ
りました。
16.6. Web ページ
情報に満ちた web ページは山ほどあります。その性質上、 web ページは頻繁
に変わるので、ここに書いたリンクが古くなっていてもどうかあまり驚かない
でください。
よい出発点は、もちろん Linux Documentation Homepage
でしょう。ここは文書やプロジェクトのペー
ジ、その他諸々に関する情報の中心です。
o DPT キャッシング RAID コントローラのドライバを書いた Mike Neuffer
が興味深いページをいくつか公開しています。
SCSI のページ と DPT の
ページ です。
o ソフトウェア RAID の開発に関する情報は Linux Kernel site
にあります。パッチやユーティリティもここに
あります。
o ベンチマーク、 RAID、信頼性、その他にも数多くのディスク関連情報が
Linas Vepstas プロジェクトのページにあります。
o ルートパーティションを RAID にする方法や、これを行うために必要なソ
フトウェアなどの情報は から入手できます。
o ext2fs に関する詳細な情報が
から入手できま
す。
o VFAT, FAT32, Joliet に関する情報を探している人は、開発ページ
を見てくださ
い。
これらのドライバは 2.1.x の開発版カーネルや 2.0.34 以降のカーネルに
取り込まれています。
あらゆるディスクドライブやコントローラなどに関する仕様・情報は、新しい
ものも古いものも The Ref か
ら入手できます。ここには有用な情報が本当にたくさんあります。まさに宝の
山です。
他にも興味深いサイトがあったら筆者まで教えてください。
16.7. 検索エンジン
どこにもなければインターネットの検索エンジンを試してみましょう。たくさ
ん種類があり、それぞれ少しづつ機能が違っています。これらをいかにフル活
用するかに関しては、この HOWTO の目的から外れていますので述べません。
Internet mini-HOWTO のトラブルシュートの章や、 Updated mini-HOWTO など
をご覧ください。
助けを求めたい場合は、 comp.os.linux.setup ニュースグループが良いで
しょう。筆者自身は、多忙なためと、ネットワーク接続が遅いために、この
ニュースグループはフォローできていません。筆者に連絡したい場合は電子
メールを使ってください。
17. 助けを求めるには
いろいろと試しても、自力だけでは問題を解決できないこともあるでしょう。
この場合は他の人に助けてもらわなければなりません。もっとも効率の良い方
法は、近くにいる人や、近所の Linux ユーザグループに尋ねたり、あるいは
近くの web を検索することです。
他の可能性として、たくさんある Usenet ニュースグループのどこかで尋ねる
こともできます。この方法の問題は、これらのグループでは流量もノイズも大
きい (S/N 比が低い、と言われます) ために、あなたの質問が答えられないま
ま放っておかれる可能性が高いことです。
どこで尋ねるにしろ、真面目に取り合ってもらうためには、上手に質問するこ
とが大事です。「僕のディスクが動きません」なんて言うだけじゃ誰も助けて
くれないでしょうし、ノイズのレベルがまた上がるだけの結果になります。運
が良ければ誰かが詳しい内容を尋ねてくれるかもしれませんけど。
そうではなく、あなたの問題をできるだけ詳細に述べて、他の人があなたを助
けることができるようにするべきです。問題の原因はあなたが思っているのと
は違うところにあるのかもしれません。ですから、あなたのシステムに関する
以下のような情報を列記すべきなのです。
ハードウェア
o プロセッサ
o DMA
o IRQ
o チップセット (LX, BX など)
o バス (ISA, VESA, PCI など)
o 使っている拡張カード (ディスクコントローラ、ビデオ、IO など)
ソフトウェア
o BIOS (マザーボードの。 SCSI ホストアダプタにもあるかも)
o 使っている場合は LILO
o Linux kernel のバージョンと、修正パッチなど
o 指定している場合はカーネルのパラメータ
o エラーを発しているソフトウェア (バージョンと日付も)
周辺機器
o ディスクドライブの形式、製造会社の名前、バージョン
o 同じバスに繋がっている他の周辺機器
これらの問題がどのように相関しているかの一例を挙げてみましょう。古い
チップセットでは、ビデオコントローラと SCSI ホストアダプタの組み合わせ
によって障害が起こることがあったりするのです。
ブート時のテキストが /var/log/messages にあること、ここには上記に関す
る答えのほとんどがあることも覚えておきましょう。ドライブに問題がある場
合は、そもそもログをセーブするディスクが無いことになりますが、でも
SHIFT と PAGE UP キーを使えば、最低限ながらスクリーンをスクロールバッ
クすることもできます。これらのログの一部分を、質問メッセージに入れても
いいでしょう。でもあまり入れすぎず、簡潔 にしておきましょう。ログファ
イルがUsenet ニュースにダンプされるのは、「ちょっとイヤだな」というレ
ベルを少々越えていますから。
18. 終わりに
ディスクの調整やパーティション分けの判断は難しい問題です。原則と言える
ものはないのが現状です。しかしこの問題に取組むことはきっと目に見える利
益を生んでくれるでしょう。あるドライブが酷使されているのに他のドライブ
は働いていない、というような状態は最適な状況ではないでしょう。ドライブ
のランプを良く見ましょう、ただの飾りで付いてるのではないんですから。正
しくセットアップされたシステムでは、これらのランプはクリスマスのディス
コのように光るでしょう。 Linux ではソフトウェア RAID が使えますし、サ
ポートされている SCSI RAID コントローラのハードウェアもあります。何が
使えるかを調べましょう。システムが大きくなり、あなたの経験が豊富になる
と、パーティションを変更したくなってくるでしょう。その時にはまたこの文
書を見てください。追加情報は常に歓迎しています。
最後に筆者のお勧めをここにまとめておきます。
o ディスクは安価ですが、そこに含まれるデータはずっとずっと価値があり
ます。システムのバックアップをしましょう。バックアップのテストもし
ましょう。
o 作業もまた高価なものです。新しいディスクを追加したり古いディスクを
再パーティションするのは時間のかかる作業ですから、充分大きなディス
クを買っておきましょう。
o 信頼性について考慮し、古いディスクは故障する前に交換しましょう。
o 設定を紙にコピーしておきましょう。すべてをディスク上にいておいたの
では、マシンがダウンしたらあまり助けにはなりません。
o 簡単な設計からはじめましょう。特殊な技術は最初はあまり用いず、のち
のち追加していくようにしましょう。一般に追加は置換よりも簡単です
が、これはディスクや技術などにもあてはまります。
18.1. 今後の予定
この文書にはいくつか重要な内容を追加する必要があります。特に、付録には
例をいくつか追加するつもりです。筆者は現在 2 つのマシンを立ち上げてい
るところです。職場で巨大なシステム、そして自宅にごく一般的なシステムで
す。この二つの例を挙げれば、どのようにシステムをセットアップするかにつ
いてだいたいの感じをつかんでもらえるものと期待しています。うまく働いて
いるシステムの例がありましたら、もちろん送っていただけると大歓迎です。
様々なファイルシステムやユーティリティに関しても、書かなければならない
ことがたくさん残っています。
ドライブの技術に関して、また fdisk や cfdisk, sfdisk の具体的な使い方
に関して、かなりの分量を追加するつもりです。利用可能になるであろうファ
イルシステムに関して、また RAID に関して、 RAID のそれぞれのレベルが具
体的にどのようなディレクトリに有益であるかに関しても増強するつもりで
す。
Linux Filesystem Structure Standard や FHS と重複しているところが少々
ありますので、できればより良い形でまとめ直したいと思っています。付録の
表は全面的に書き直す必要があるでしょう。
多くの人々がこの文書を読むにつれ、コメントやフィードバックも多数寄せら
れることと思います。現在筆者は、この文書で述べたディレクトリ配置の決定
プロセスを自動化するようなプログラムができないかと考えています。最適な
配置を吐き出すのはなかなか難しいでしょうが、スタートポイントとしてふさ
わしい簡潔な結果を出せるようになると良いと思います。
18.2. 情報募集
この文書を書きはじめてから随分経ち、多くの部分が統合されつつあります
が、まだこの文書をベータからリリース版にするには以下のような情報が必要
です。
o スワップサイズの決定法に関するより多くの情報、またそれぞれのカーネ
ルのバージョンで利用できる最大のスワップサイズに関する情報。
o ドライブやファイルシステムは、どの程度の頻度で壊れるものなのか。
o ドライブの速度に関する基準。
o Linux で利用可能な他の RAID コントローラの情報。
o ディスクの監視・管理・メンテナンスに良いツールがあるか？
o 情報源に関する一般的な参考情報。別の文書にするべきか？
o /tmp と /var/tmp の利用法を決定するのは今のところ難しく、どのプログ
ラムがこれらのディレクトリを利用しているのかもよく分かっていませ
ん。情報がありましたら知らせてください。しかし、少なくともこれらを
別の物理ドライブに置いて、並列性を高めるべきであることは明らかなよ
うです。
18.3. 著者が提案するプロジェクト
comp.os.linux.* ニュースグループには「何かプロジェクトをやりたいんだけ
ど、良いアイディアはないですか」という投稿が時々寄せられます。ここで
は、この文書を書いているうちに筆者が思い付いたものをいくつか記します。
ファイルシステムのような大きなプロジェクトでは、共同作業者を探したり手
を着けている人がいないかを調べたりする必要がありますから、ニュースへの
ポストが必要かもしれません。
設計ツール
先に述べたような、パーティション分割の作業を自動化するようなツー
ルは中規模のプロジェクトになるでしょう。制限付き問題を解決するプ
ログラムの練習になるでしょう。
パーティション分割ツール
設計ツールの出力を受け、ドライブをフォーマットし、ディレクトリ構
造に適宜必要なシンボリックリンクをあてがってくれるものです。シス
テムのインストールソフトと統合されるとベストでしょう。 Solaris
についているパーティション分割ツールが良いお手本になるでしょう。
監視ツール
パーティションのサイズを監視し、あふれる前に警告してくれるツール
です。
移動ツール
安全にディレクトリ構造を古いドライブから新しいドライブ (例えば
RAID など) へ移動してくれるものです。多分簡単で、バックアップ用
のプログラムをコントロールするシェルスクリプトでも実現できるかも
しれません。しかし安全であるかどうか、移動後に変更がないかどうか
はしっかりチェックされなければなりません。
19. Q & A
よくありそうな質問であると判断したものを集めました。読者からのフィード
バックを期待します。そうすれば、この節はちゃんとした FAQ にできるで
しょう。
o Q: Linux に必要な物理ディスクドライブは何台でしょう？
A: Linux は一台のドライブでもちゃんと動作します。スワッピングを避け
るためには、 2 台目のディスクを買うよりも充分な RAM (32〜64 MB 程
度) を用意する方がコストパフォーマンスとしては良いでしょう。ディス
クとしては (E)IDE の方が SCSI よりも安いようです (ただし多少遅いで
す)。
o Q: 私はドライブを一台しか使っていないんですが、この HOWTO は役に立
ちますか？
A: はい。しかし度合いは少々低くなるかもしれません。それでも ``ト
ラックの配置'' の節はきっと有益でしょう。
o Q: この HOWTO の手法の欠点は？
A: 一つあります。どれかのパーティションがあふれると、システムがちゃ
んと動作しなくなってしまいます。どの程度深刻な問題になるかはもちろ
んあふれたパーティションに依存します。しかしパーティションがあふれ
ないように監視することはそれほど難しくなく、 df を実行すれば現状の
概要はわかります。またスワップのパーティションも free でチェックし
て、仮想メモリ領域を使い切らないように注意しましょう。
o Q: なるほど、では私はそれぞれのドライブをできるだけ多くのパーティ
ションに区切るべきなんですね？
いいえ。あまり多すぎても問題が生じます。まず管理が必要以上に複雑に
なってしまいます。一方パーティションが大きすぎると、これまた必要以
上にシーク動作が長くかかってしまうことになります。これらのバランス
をよく考えて決めてください。使っているドライブの台数にもよるでしょ
う。
o Q: ということはドライブが多くなるとパーティションも多くするべきなの
ですか？
A: ある意味ではそうです。しかしルートから分割すべきではないディレク
トリがあることに注意してください。詳細はファイルシステムに関する標
準化文書を参考にしてください。
o Q: ドライブを多数利用したいときにはどうすべきでしょう？
A: 3〜4 台以上のドライブを使う場合は RAID を考慮すべきだと思いま
す。しかしその場合もルートパーティションは RAID でないパーティショ
ンに置いておく方がよいでしょう。詳しくは ``RAID'' の章を参考にして
ください。
o Q: 最新版の Windows95 を入れたパーティションが Linux から見えませ
ん。何が悪いんでしょう？
A: そのパーティションが FAT32 になっている可能性が一番高いと思いま
す。これは Microsoft が最新版の Windows95 (OSR2) に導入したファイル
システムです。 FAT32 の利点は大きなドライブの利用に向いていることで
す。
Microsoft NT 4.0 でもまだサポートされていないファイルシステムだ、と
言うことも知っておいて良いかもしれません。
o Q: ディスク容量と各パーティションの容量が合いません。足りない分はど
こに行っちゃったんでしょう？
A: マウントポイントのディレクトリが空でなかった可能性があります。こ
の場合、マウント前の内容は隠されてしまい、このディレクトリの容量分
がディスクから消えてしまったように見えることがあります。
この場合はレスキューディスクなどを使ってブートし、マウントポイント
に隠れてしまっているファイルを消去するか、あるいは一時領域に非難さ
せて下さい。緊急用にマウントポイントのスペアを作っておくと便利かも
しれません。
o Q: 私のスワップパーティションは使われてないみたいなんですが、どうし
てでしょう？
A: スワップアウトの必要がなかったのかもしれません。特に RAM が充分
ある場合は、その可能性が高いですね。ログファイルをチェックして、あ
る瞬間にメモリを使い切った旨の記録があるか調べてください。記録があ
れば、スワップパーティションは置いておく必要があったのです。記録が
なければ、スワップパーティションが正しい番号に割り当てられていな
かったり、 mkswap していなかったり、 swapon していなかったり
/etc/fstab ファイルへ追加していないのかもしれません。
o Q: 何回か Nyx って言葉が出てきますけど、これはなんですか？
A: 誰でも自由に使うことのできる大きな Unix システムで、現在 10000
人ほどのユーザがいます。筆者はこの HOWTO の web ページを nyx に置い
ています。また大きな Unix システムの設定に関するアイディアの源でも
あります。長いこと非常に安定して動作しています。詳しい情報は Nyx
Homepage をご覧ください。無料アカウントの取得
方法についても記述があります。
20. 補遺
この章は未分類の情報を集めたものです。それぞれの情報はそれなりに面白い
と思います。一時的な領域だと思ってください。
20.1. スワップパーティション: 使うべきか使わざるべきか？
スワップパーティションを必要としない場合も少なくありません。例えば RAM
が充分にあり (64 MB くらいでしょうか)、またユーザが一人しかいないよう
な場合です。このような場合は実験的にスワップパーティション無しでシステ
ムを運用し、仮想メモリを使い切っていないかをシステムのログで確認してみ
ても良いでしょう。
スワップパーティションを使わない選択には以下のような利点があります。
o (あたりまえですが) ディスクスペースの節約になります。
o スワップパーティションはシークに有利なディスクの真ん中に置かれるこ
とが多いので、スワップを省略すれば代わりに高速アクセスが必要とされ
るパーティションを置くことができます。
簡単に言えば、スワップパーティションは便座の暖房機能みたいなものです。
そんなに頻繁に使うものではないですが、必要な時にはその存在は非常にあり
がたいものです。
20.2. マウントポイントと /mnt
この文書の以前の版では、各種のマウントポイントを /mnt 以下のサブディレ
クトリにしていました。しかしこれは良い考えではありませんでした。なぜな
ら /mnt 自身がマウントポイントとして使われると、それ以下のディレクトリ
がアクセス不可能になってしまうからです。この版からは、代わりにマウント
ポイントをルートファイルシステム直下に /mnt.descriptive-name と言うか
たちで記述するようにしました。
最近気づいたのですが、 Linux の配布パッケージによってはマウントポイン
トを /mnt 以下のサブディレクトリ (/mnt/floppy とか /mnt/cdrom など！)
にしているものもあるようです。状況の混乱を示す一例といえます。 FHS に
よって解決するとよいのですが。
20.3. 電力と発熱
現代の PC と同じような性能の計算機が三相電源と専用の冷却 (大抵は空冷と
マシンルームの空調でしたが、水冷のものもありました) を必要としていた時
代はそんなに古いことではありません。技術の急速な進歩は、高速化だけでな
く部品の低電力化をももたらしました。しかしそれでも限界というものはあり
ます。ディスクや PCI カードを追加することによってシステムが大きくなる
ごとに、電力のことを考えておく必要があります。電源が供給する電力は、そ
のほとんどが熱になります。もしこの熱がファンによって逃げなければ、ケー
ス内部は相当な温度になり、電子パーツの性能や寿命の低下の原因になりま
す。メーカーは冷却に関する推奨値を挙げているはずで、通常は立方フィート
毎分 (CFM) 単位の数値です。この数値は真面目に考えておく方が良いと思い
ます。
空気の通り道を確保し、ほこりを払って、システムが動作中の温度を測ってみ
ましょう。触れないくらい熱くなっていたら、それは少々問題です。
可能ならドライブにシーケンシャルスピンアップを用いるようにしましょう。
ドライブは円板の回転加速に最大の電力を必要とするので、すべてのドライブ
を同時にスタートさせると電源の電力許容値を越えてしまう可能性がありま
す。
20.4. Deja
これはインターネットのサイトで、おそらく読者の多くがすでに利用している
ことでしょう。ここでは 1995 年から最新のポストに至るまでの Usenet
ニュースの記事を検索・閲覧できます。また WWW を通してニュースの購読や
ポストを行うこともできます。他にも色々な機能があります。 Deja
に行ってみてください。 Dejanews から名前が変わり
ました。
こちらはあまり知られていないでしょうが、このサイトは Linux で動作して
いる、およそ 120 台の SMP コンピュータで運用されています。それぞれは
md モジュールを用いて 4〜24 GB のディスクを利用しています (全体で 1200
GB 以上)。システムは大きくなり続けていますが、本文書の執筆現在では、そ
れぞれが dual Pentium Pro 200 MHz または Peintium II 300 MHz のシステ
ムで、 256 MB 以上の RAM を積んでいます。
データベースを生成するマシンは一台のディスクを OS 用に利用し、 4〜6 台
のディスクを md モジュールで管理して、記事のアーカイブに当てています。
ドライブは BusLogic の BT-946C PCI SCSI アダプタに接続されています (だ
いたい一台につき二枚)。
生成システム (年 365 日可動します) での、ディスクエラーによるダウンタ
イムは 0.25 % 以下だそうです (25% じゃないですよ!)。
これは事例紹介であって、宣伝しているわけではありません。メジャーなイン
ターネットサービスにどの程度のハードウェアが必要になるのか、例として挙
げているだけです。
20.5. クラッシュリカバリ
たまにはハードディスクもクラッシュします。クラッシュによって乱された
データでも、少なくとも部分的には復旧できることが多く、その手法を解説し
た HOWTO も既に存在しています。
ハードウェアの障害の場合には、事情はかなり深刻になります。この場合には
2 つの選択肢があります。そのドライブをデータ回復の専門業者に送るか、自
分でやってみるか、です。もちろん後者は リスクの高い 方法であり、より被
害が大きくなることもありえます。
ディスクが回転を止めてしまい、再度回らなくなったときは、まず最初のアド
バイスは「システムを可能な限り安全に停止せよ」です。
次にドライブの接続を外し、マシンの電源を入れ、テスターで電源が正しいか
どうかチェックしてみましょう。コネクタが接続不良になることは極めて多
く、これはあらゆる障害の原因になりえます。
自分で行うリスクを覚悟した場合は、コネクタを全部チェックしたら、もう一
度電源を入れ、ドライブがスピンアップするか、反応するか見てみましょう。
それでも死んでいる場合は速やかに、できれば OS がブートする前に電源を切
りましょう。ここでは時間差スピンアップによって騙されないよう注意するこ
と。
さらに先に進むことに (そしてより高いリスクを背負うことに) 決めたなら、
ドライブを外し、側面を少々強めに叩いて、ディスクをケースに対して少し動
かしてみてください。ヘッドが表面から離れないのが原因の場合 (モーターの
力だけではヘッドを離すのに足りなかったわけで)、この衝撃によってプラッ
タが再び自由に動けるようになる可能性もあります。
また、ドライブを長期間使いつづけた後 (あるいは加熱されすぎた後) しばら
くオフにしておくと、潤滑剤がベアリングから流れ去って固まってしまうこと
があります。この場合はドライブをゆっくり優しく通常の動作温度にまで温め
てあげると、潤滑の問題は修復できることがあります。
ここまで来てもドライブが反応しない場合、最後の、そして最もリスクの高い
提案は、ドライブの回路基板を、同じモデルのドライブと交換してみることで
す。
ドライブの内容はメディアよりもはるかに高価であることが多いですから、専
門業者の助けを借りることを是非考慮してください。これらの会社にはより高
度な機器や、ダメージを受けたドライブの復旧に関して製造業者から得たノウ
ハウが、アマチュアに比べてはるかに揃っています。
21. 付録 A: パーティション配置表: マウントとリンク
以下に示した表は、パーティション配置を紙とエンピツで簡単に行えるように
したものです。プリントアウトして (プロポーショナルフォントは使わないよ
うに！) 満足行くまで番号合わせを行なうのが良いでしょう。
マウントポイント (Mount point) は、実際のパーティションまたはデバイス
をマウントするディレクトリです。ここにはシンボリックリンクとするかどう
かも書いておくと良いでしょう。
ここにある容量は Debian 1.2.6 で比較的たくさんの物をインストールした場
合に対応しています。他の例もそのうち追加するつもりです。
この表はどんなディレクトリ構造やドライブを使うかを決めるのに用いると良
いでしょう。実際のパーティション番号は、続く 2 つの表で決めます。
Directory Mount point speed seek transfer size SIZE
swap __________ ooooo ooooo ooooo 32 ____
/ __________ o o o 20 ____
/tmp __________ oooo oooo oooo ____
/var __________ oo oo oo 25 ____
/var/tmp __________ oooo oooo oooo ____
/var/spool __________ ____
/var/spool/mail __________ o o o ____
/var/spool/news __________ ooo ooo oo ____
/var/spool/____ __________ ____ ____ ____ ____
/home __________ oo oo oo ____
/usr __________ 500 ____
/usr/bin __________ o oo o 250 ____
/usr/lib __________ oo oo ooo 200 ____
/usr/local __________ ____
/usr/local/bin __________ o oo o ____
/usr/local/lib __________ oo oo ooo ____
/usr/local/____ __________ ____
/usr/src __________ o oo o 50 ____
DOS __________ o o o ____
Win __________ oo oo oo ____
NT __________ ooo ooo ooo ____
/mnt._________ __________ ____ ____ ____ ____
/mnt._________ __________ ____ ____ ____ ____
/mnt._________ __________ ____ ____ ____ ____
/_____________ __________ ____ ____ ____ ____
/_____________ __________ ____ ____ ____ ____
/_____________ __________ ____ ____ ____ ____
Total capacity:
22. 付録 B: パーティション配置表: 番号付けと容量の割り振り
この表は上の表と同じディレクトリ構造が並んでいますが、どのディスクを使
うかを決めるために使います。ここではディスク上での配置を決めます。この
文書の ``トラックの配置'' の節で紹介した、セクタの位置による効果を心に
留めながら行ってください。
最終的なパーティションの番号はこの次の表に書きます。
Drive sda sdb sdc hda hdb hdc ___
SCSI ID | __ | __ | __ |
Directory
swap | | | | | | |
/ | | | | | | |
/tmp | | | | | | |
/var : : : : : : :
/var/tmp | | | | | | |
/var/spool : : : : : : :
/var/spool/mail | | | | | | |
/var/spool/news : : : : : : :
/var/spool/____ | | | | | | |
/home | | | | | | |
/usr | | | | | | |
/usr/bin : : : : : : :
/usr/lib | | | | | | |
/usr/local : : : : : : :
/usr/local/bin | | | | | | |
/usr/local/lib : : : : : : :
/usr/local/____ | | | | | | |
/usr/src : : : :
DOS | | | | | | |
Win : : : : : : :
NT | | | | | | |
/mnt.___/_____ | | | | | | |
/mnt.___/_____ : : : : : : :
/mnt.___/_____ | | | | | | |
/_____________ : : : : : : :
/_____________ | | | | | | |
/_____________ : : : : : : :
Total capacity:
23. 付録 C: パーティション配置表: パーティションの作成
この表は fdisk や cfdisk の入力に便利なように、パーティションの番号順
に並び替えたものです。ここで配置を完成させる際、やはりセクタの配置は考
慮に入れておくようにしてください。特に他に情報がなければ、トラック 0
が最外周と思ってよいでしょう。
この番号とドライブレターは前の 2 つの表を更新するときに使うと良いで
しょう。きっと後々メンテナンスが非常に楽になると思います。
ディスククラッシュが起こった場合などには、 SCSI ID とドライブの対応が
付けにくくなるものです。これは紙にコピーして保存しておきましょう。
Drive : sda sdb sdc hda hdb hdc ___
Total capacity: | ___ | ___ | ___ | ___ | ___ | ___ | ___
SCSI ID | __ | __ | __ |
Partition
1 | | | | | | |
2 : : : : : : :
3 | | | | | | |
4 : : : : : : :
5 | | | | | | |
6 : : : : : : :
7 | | | | | | |
8 : : : : : : :
9 | | | | | | |
10 : : : : : : :
11 | | | | | | |
12 : : : : : : :
13 | | | | | | |
14 : : : : : : :
15 | | | | | | |
16 : : : : : : :
24. 付録 D: 例 1: 多目的サーバ
以下の表は、筆者がかつての勤務先で中規模の多目的サーバをセットアップし
たときのものです。通常の Linux マシンとしての機能に加え、ネットワーク
関係のサーバ (DNS、 mail、 ftp、 news、プリントサーバ など) としても働
いています。またいろいろな CAD プログラム用の X サーバや CD-ROM ライタ
など、様々な用途に使っています。 3 台の SCSI ドライブがついていて、容
量はそれぞれ 600、1000、1300 MB です。
/usr/local を /usr から独立させればより速度が向上するとは思いますが、
これ以上のシステムの複雑化には見合わないと判断しました。ドライブが追加
されれば考える価値が高まるかもしれません。 sda は古くて遅いドライブ
で、せいぜい IDE 程度の性能しかありません。他の 2 台はもっと高速です。
基本的に後者の 2 台に負荷を分割してかけるようにしています。パーティ
ション容量の偏りが生じないように、 /usr/bin と /usr/local/bin はひとつ
のドライブに、そして /usr/lib と /usr/local/lib をもうひとつのドライブ
に配置しました。これによってドライブ利用の並列化もある程度達成できまし
た。
RAID を使えばさらにパフォーマンスは向上するでしょうが、現在利用できる
md パッチはサーバに用いるにはまだ信頼性に欠けると判断しました。本物の
RAID コントローラには手が届きませんでした。
25. 付録 E: 例 1: マウントとリンク
Directory Mount point speed seek transfer size SIZE
swap sdb2, sdc2 ooooo ooooo ooooo 32 2x64
/ sda2 o o o 20 100
/tmp sdb3 oooo oooo oooo 300
/var __________ oo oo oo ____
/var/tmp sdc3 oooo oooo oooo 300
/var/spool sdb1 436
/var/spool/mail __________ o o o ____
/var/spool/news __________ ooo ooo oo ____
/var/spool/____ __________ ____ ____ ____ ____
/home sda3 oo oo oo 400
/usr sdb4 230 200
/usr/bin __________ o oo o 30 ____
/usr/lib -> libdisk oo oo ooo 70 ____
/usr/local __________ ____
/usr/local/bin __________ o oo o ____
/usr/local/lib -> libdisk oo oo ooo ____
/usr/local/____ __________ ____
/usr/src ->/home/usr.src o oo o 10 ____
DOS sda1 o o o 100
Win __________ oo oo oo ____
NT __________ ooo ooo ooo ____
/mnt.libdisk sdc4 oo oo ooo 226
/mnt.cd sdc1 o o oo 710
Total capacity: 2900 MB
26. 付録 F: 例 1: 番号付けと容量の割り振り
ここで容量と配置の調整をします。
Directory sda sdb sdc
swap | | 64 | 64 |
/ | 100 | | |
/tmp | | 300 | |
/var : : : :
/var/tmp | | | 300 |
/var/spool : : 436 : :
/var/spool/mail | | | |
/var/spool/news : : : :
/var/spool/____ | | | |
/home | 400 | | |
/usr | | 200 | |
/usr/bin : : : :
/usr/lib | | | |
/usr/local : : : :
/usr/local/bin | | | |
/usr/local/lib : : : :
/usr/local/____ | | | |
/usr/src : : : :
DOS | 100 | | |
Win : : : :
NT | | | |
/mnt.libdisk | | | 226 |
/mnt.cd : : : 710 :
/mnt.___/_____ | | | |
Total capacity: | 600 | 1000 | 1300 |
27. 付録 G: 例 1: パーティションの作成
fdisk や cfdisk の入力時に楽なように、パーティション番号の順番に並び替
えたものです。トラック上の物理的配置に対する最適化を忘れないように (こ
こではしていませんが)。
Drive : sda sdb sdc
Total capacity: | 600 | 1000 | 1300 |
Partition
1 | 100 | 436 | 710 |
2 : 100 : 64 : 64 :
3 | 400 | 300 | 300 |
4 : : 200 : 226 :
28. 付録 H: 例 2
以下は nakano (at) apm.seikei.ac.jp より寄せられた大学での利用例です。
/var/spool/delegate は WWW のプロキシサーバプログラム delegated のログ
やキャッシュのためのディレクトリです。今のところ使っている人数は少な
く、一日あたり 1000〜1500 アクセスに収まっています。毎日キャッシュの更
新を行っており、ディスクの利用率は 15〜30 % 程度です。
/mnt.archive は、巨大かつあまり頻繁には利用されないファイルを置いてあ
ります。たとえば実験データ (特にグラフィックデータ) や各種のソース、
Win 95 マシンのバックアップなどです。
/mnt.root はルートファイルシステムのバックアップで、レスキュー用のユー
ティリティが入っています。このパーティションから立ち上げるためのブート
フロッピーも別に用意してあります。
=================================================
Directory sda sdb hda
swap | 64 | 64 | |
/ | | | 20 |
/tmp | | | 180 |
/var : 300 : : :
/var/tmp | | 300 | |
/var/spool/delegate | 300 | | |
/home | | | 850 |
/usr | 360 | | |
/usr/lib -> /mnt.lib/usr.lib
/usr/local/lib -> /mnt.lib/usr.local.lib
/mnt.lib | | 350 | |
/mnt.archive : : 1300 : :
/mnt.root | | 20 | |
Total capacity: 1024 2034 1050
=================================================
Drive : sda sdb hda
Total capacity: | 1024 | 2034 | 1050 |
Partition
1 | 300 | 20 | 20 |
2 : 64 : 1300 : 180 :
3 | 300 | 64 | 850 |
4 : 360 : ext : :
5 | | 300 | |
6 : : 350 : :
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda1 19485 10534 7945 57% /
/dev/hda2 178598 13 169362 0% /tmp
/dev/hda3 826640 440814 343138 56% /home
/dev/sda1 306088 33580 256700 12% /var
/dev/sda3 297925 47730 234807 17% /var/spool/delegate
/dev/sda4 363272 170872 173640 50% /usr
/dev/sdb5 297598 2 282228 0% /var/tmp
/dev/sdb2 1339248 302564 967520 24% /mnt.archive
/dev/sdb6 323716 78792 228208 26% /mnt.lib
明らかに /tmp と /var/tmp は大きすぎるようです。将来ディスクが足りなく
なったときには、これらのディレクトリは一つのパーティションにまとめるべ
きかもしれません。
/mnt.lib もちょっと大きすぎるようですが、そのうち TeX と ghostscript
の新しいバージョンをインストールするつもりですので、 /usr/local/lib は
すぐに 100 MB 程度膨らむのではないかと考えています (日本語フォント関連
が多分巨大なので)。
システム全体は Seagate TapeStore 8000 (Travan TR-4 4G/8G) でバックアッ
プをとっています。
29. 付録 I: 例 3: SPARC Solaris
以下は Solaris 2.5.1 を走らせている Sun SPARC サーバの基本的なデザイン
の例です。これらのシステムは実際に仕事で使っており、技術開発の用途に用
いています。通常のメール配送などのジョブに加え、多くのデータベースや
CAD アプリケーションを提供しています。
ここではシンプルであることが重要なので、 /usr/lib は /usr から分離して
いません。
だいたい 100 人ほどのユーザ向けに作られた基本レイアウトです。
Drive: SCSI 0 SCSI 1
Partition Size (MB) Mount point Size (MB) Mount point
0 160 swap 160 swap
1 100 /tmp 100 /var/tmp
2 400 /usr
3 100 /
4 50 /var
5
6 remainder /local0 remainder /local1
このサーバには特殊な要求があり、たまに大きなパーティションが (短い間で
はありますが) 必要になる場合があります。そのためドライブ 0 にできるだ
け多くの役割を割り当て、 /local1 に大きなパーティションを残すようにし
てあります。
この設定で長い間使っていますが、特に不満は生じていません。
より一般的なシステムでは、 /tmp や /var/tmp、さらに /var などをドライ
ブ 1 に移動すると良いかもしれません。
30. 付録 J: 例 4: ドライブ 4 台のサーバ
ここでは、これまでに述べてきたすべてのテクニック (RAID 以外) をすべて
使っています。確かに少々複雑ですが、普通のハードウェアから高い性能を引
き出すことができます。実際に割り当てた大きさは省略しますが、前の例から
適当な大きさを見積もることができると思います。
Partition sda sdb sdc sdd
---- ---- ---- ----
1 root overview lib news
2 swap swap swap swap
3 home /usr /var/tmp /tmp
4 spare root mail /var
この設定はトラックの配置・ドライブシークのいずれに対しても最適化されて
います。
DOS や Windows も使いたい場合は、 sda1 をあてがってやる必要がありま
す。その後他のパーティションを移動させます。スワップパーティションであ
る sdb2, sdc2, sdd2 は、 Windows セッションの間は Windows のスワップや
TEMPDIR、 Windows 自身の一時ディレクトリなどに利用できると効率が良いで
しょう。一台のマシンに複数の OS を共存させる方法については、他にたくさ
んの HOWTO が出ています。
完全を期すために、いくつかのタイプの RAID を用いた 4 台構成のシステム
についても以下に例を与えておきましょう。上の例よりもさらに複雑な構成に
なっています。
Partition sda sdb sdc sdd
---- ---- ---- ----
1 boot overview news news
2 overview swap swap swap
3 swap lib lib lib
4 lib overview /tmp /tmp
5 /var/tmp /var/tmp mail /usr
6 /home /usr /usr mail
7 /usr /home /var
8 / (root) spare root
ダブっているものは、すべて RAID 0 のセットです。ただし swap は例外で、
これはインターリーブされている swap パーティションです。 home と mail
は、安全のために RAID 1 として構成されています。
boot と root が分離されていることに注意してください。 boot ファイルと
カーネルは 1023 シリンダよりも低位に置く必要があります。残りの root の
ファイルはどこにおいてもかまいません。ここでは最も低速な最内周のパー
ティションに配置しています。わかりやすさと安全性のため、 root パーティ
ションは RAID システムにはしていません。
このような複雑な設定では fstab ファイルも複雑になります。パーティショ
ンの数が増えると、 fsck を正しい順序で行わせることが大事になってきま
す。下手な設定では、最適な設定に比べて 10 分以上遅くなってしまうことも
あり得ると思います。
/dev/sda8 / ? ? 1 1 (a)
/dev/sdb8 / ? noauto 1 2 (b)
/dev/sda1 boot ? ? 1 2 (a)
/dev/sdc7 /var ? ? 1 2 (c)
/dev/md1 news ? ? 1 3 (c+d)
/dev/md2 /var/tmp ? ? 1 3 (a+b)
/dev/md3 mail ? ? 1 4 (c+d)
/dev/md4 /home ? ? 1 4 (a+b)
/dev/md5 /tmp ? ? 1 5 (c+d)
/dev/md6 /usr ? ? 1 6 (a+b+c+d)
/dev/md7 /lib ? ? 1 7 (a+b+c+d)
括弧の内部の文字は、それぞれの fsck のパスでどのドライブが使われている
かを示します。これらの文字は実際の fstab ファイルには書いてはいけませ
ん。結局 7 段階のパスを使うことになりました。
31. 付録 K: 例 5: ドライブ 2 台のシステム
ドライブ 2 台の構成では、賢い配置にするといってもできることはあまり多
くありませんが、以下のシンプルな構成を出発点とすると良いでしょう。
Partition sda sdb
---- ----
1 boot lib
2 swap news
3 /tmp swap
4 /usr /var/tmp
5 /var /home
6 / (root)
複数 OS のシステムを使っている場合には、他の OS の多くがブートパーティ
ションとして第一ドライブの第一パーティションを必要とすることに注意して
ください。簡単な DOS / Linux システムは以下のようにできるでしょう。
Partition sda sdb
---- ----
1 DOS lib
2 boot news
3 swap swap
4 /tmp /var/tmp
5 /usr /home
6 /var DOSTEMP
7 / (root)
DOS と Windows では、基本パーティションはドライブあたり一つにしてお
き、それはディスクの先頭に置いて、そこから DOS・Windows をブートさせる
構成にしておくと良いでしょう。嬉しいことに Linux は論理パーティション
にも置くことができますから、これは大きな問題にはならないでしょう。
32. 付録 L: 例 6: ドライブ 1 台のシステム
これはこの HOWTO の主題からは少々外れますが。最近では確かに巨大なディ
スクが入手できるようになりました。 10〜20 GB のドライブが普通になりつ
つあり、このようなモンスターをどう分割すべきか、という質問がしばしば尋
ねられるようになりました。一方おもしろい事に、このようなドライブをどう
すれば一杯にできるかについての質問は全く無いみたいですね。さらに大きな
ドライブを開発しているメーカーにとって、未来はバラ色のようです。
最適化を行えるチャンスは、 2 台構成の場合に比べても当然さらに小さくな
りますが、トラックの位置に基づいた最適化やヘッド移動を最小化するための
テクニックは多少は有効です。
Partition hda Size estimate (MB)
---- ------------------
1 DOS 500
2 boot 20
3 Winswap 200
4 data The bulk of the drive
5 lib 50 - 500
6 news 300+
7 swap 128 (Maximum size for 32-bit CPU)
8 tmp 300+ (/tmp and /var/tmp)
9 /usr 50 - 500
10 /home 300+
11 /var 50 - 300
12 mail 300+
13 / (root) 30
14 dosdata 10 ( Windows bug workaround!)
dosdata パーティションは DOS ファイルシステムで、これはドライブの最終
パーティションに置かなければいけません。これがないと Windows が混乱し
てしまいます。
33. 付録 M: ディスクシステム記述スクリプト
このシェルスクリプトは Steffen Hulegaard が提供してくださったもので
す。 root (スーパーユーザー) で実行するとディスクのセットアップのサマ
リを生成します。設計した内容を実装しおわったらこのスクリプトを実行し、
設計と比較して間違いがないかをチェックするといいでしょう。お使いのシス
テムに障害が発生した際にも、このスクリプトの結果は復旧の出発点として役
に立つでしょう。
______________________________________________________________________
#!/bin/bash
#$Header:$
#
# makediskdoc Collects storage/disk info via df, mount,
# /etc/fstab and fdisk. Creates a single
# reference file -- /root/sysop/doc/README.diskdoc
# Especially good for documenting storage
# config/partioning
#
# 11/11/1999 SC Hulegaard Created just before RedHat 5.2 to
# RedHat 6.1 upgrade
# 12/31/1999 SC Hulegaard Added sfdisk -glx usage just prior to
# collapse of my Quantum Grand Prix (4.3 Gb)
#
# SEE ALSO Other /root/bin/make*doc commands to produce other /root/sysop/doc/README.*
# files. For example, /root/bin/makenetdoc.
#
FILE=/root/sysop/doc/README.diskdoc
echo Creating $FILE ...
echo ' ' > $FILE
echo $FILE >> $FILE
echo Produced By $0 >> $FILE
echo `date` >> $FILE
echo ' ' >> $FILE
echo $Header$ >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION: df -a >> $FILE
df -a >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION: df -ia >> $FILE
df -ia >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION: mount >> $FILE
mount >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION: /etc/fstab >> $FILE
cat /etc/fstab >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION: sfdisk -s disk device size summary >> $FILE
sfdisk -s >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION: sfdisk -glx info for all disks listed in /etc/fstab >> $FILE
for x in `cat /etc/fstab | egrep /dev/[sh] | cut -c 0-8 | uniq`; do
echo ' ' >> $FILE
echo $x ============================= >> $FILE
sfdisk -glx $x >> $FILE
done
echo ' ' >> $FILE
echo DESCRIPTION: fdisk -l info for all disks listed in /etc/fstab >> $FILE
for x in `cat /etc/fstab | egrep /dev/[sh] | cut -c 0-8 | uniq`; do
echo ' ' >> $FILE
echo $x ============================= >> $FILE
fdisk -l $x >> $FILE
done
echo ' ' >> $FILE
echo DESCRIPTION: dmesg info on both sd and hd drives >> $FILE
dmesg | egrep [hs]d[a-z] >> $FILE
echo '' >> $FILE
echo Done >> $FILE
echo Done
exit
______________________________________________________________________
一覧に戻る
グリーンネット・トップページへ戻る
|
